Subject: Re: Sub package proposal
To: TAKEMURA Shin <email@example.com>
From: Alistair Crooks <AlistairCrooks@excite.com>
Date: 11/06/2000 06:39:03
My apologies for taking so long to respond, but I've been thinking of the
ramifications of this.
In general, when I'm trying to assess the benfits and disadvantages of a
change that I'm going to make, I prefer to take an existing package, and see
what I have to do to change it to work with my new changes - I'd strongly
recommend it over an invented foo or bar package.
In general, I like the idea of sub-packages, but I believe that we'd have to
make a lot of changes to pkgsrc to accommodate sub-packages, and I'm not
convinced that all that upheaval would be worth it. And, yes, there's a
Cassiopeia E105 with an 80 Mb CF card sitting right here, and I would dearly
love it to...
And so onto my quibbles:
1. You need to modify what is currently the "install" target for every
package to be "install-doc", "install-bin", "install-lib" etc, depending on
what sub-packages need to be installed. You might think that a workaround
would be to install everything, and then simply delete that which you don't
want, but (a) I dislike that approach in general, and (b) problems with
filesystems at or near the high-water mark, which have room for the bin
sub-package and not the doc sub-package rear their ugly heads.
2. You should really split out the PLIST files into sub-files, e.g.
PLIST-doc, PLIST-bin, PLIST-lib etc, one for every sub-package, and then use
those to install sub-packages. The complete PLIST could be constructed using
the sub-package PLISTs.
3. I'm not convinced that sub-packages are actually necessary, since most of
their contents can be decided either by their location or by their
filenames. By doing things this way, you cut out a lot of the redundant
information that would be in sub-package PLISTs, etc, and (I believe)
obviate the need for adding to the syntax already in the PLISTs. e.g. in
bsd.pkg.mk, we have a gonzo regular expression which matches the manual
pages for all packages, which seems to work fine. The same could be done for
bin sub-packages, lib sub-packages, example sub-packages etc. We're still
running into the problems as laid out in (1) above, though.
On Sun, 29 Oct 2000 19:24:24 +0900, TAKEMURA Shin wrote:
> I've wrote new pkg_* commands for my proposal.
> Of course, I'd considered some comments in this ML. Thank
> you for your informative comments. But I've omitted subpackage
> dependency issue...
> I've changed from my proposal in these poins:
> - pkg_add command line usage
> pkg_add foo-1.0.tgz +man -> pkg_add -s man foo-1.0.tgz
> - enhance @if directive
> you can use !, &&, || and () at condition expression.
> - subpackage names
> core ext dev sample man doc
> -> core runtime ext dev example man doc
> runtime subpackage should contain shared objects.
> Please try:
> source code tarball
> binary executive(./usr/sbin/pkg_*)
> diffs against current cvs
> foo.tgz, bar.tgz
> very simple packages for testing
> They have two subpackages, core and man.
> The foo depends on bar.
> pkg_add -v foo.tgz
> -> all files will be installed
> export PKG_DEFAULT_SUBPKGS='core'
> pkg_add -v -s man foo.tgz
> -> foo-core, foo-man and bar-core will be installed
> export PKG_DEFAULT_SUBPKGS='core man'
> pkg_add -v -s -man foo.tgz
> -> foo-core, bar-core and bar-man will be installed
Alistair Crooks (firstname.lastname@example.org)
Say Bye to Slow Internet!