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.

Regards,
Alistair 

On Sun, 29 Oct 2000 19:24:24 +0900, TAKEMURA Shin wrote:

>  Hi
>  
>  I've wrote new pkg_* commands for my proposal.
>  (http://mail-index.netbsd.org/tech-pkg/2000/10/21/0002.html)
>  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:
>  http://www02.u-page.so-net.ne.jp/ca2/takemura/tmp/pkg_install/
>  
>  pkg_install.20001029.src.tgz
>  	source code tarball
>  pkg_install.20001029.bin.tgz
>  	binary executive(./usr/sbin/pkg_*)
>  pkg_install.20001029.patch
>  	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.
>  
>  example:
>  	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
>  
>  Takemura
>  


--
Alistair Crooks (agc@pkgsrc.org)





_______________________________________________________
Say Bye to Slow Internet!
http://www.home.com/xinbox/signup.html