"Johnny C. Lam" <jlam@NetBSD.org> writes:

> I've attached a proposal to allow generating multiple subpackages from
> a single package directory.  I would appreciate comments on:
> 
>    (1) why this is a bad idea in pkgsrc;

Are you kidding? :)

>   (2) Every subpackage has all of the "real" dependencies of the main
>       package.

> These two constraints are a byproduct of generating all of the
> subpackages from a single Makefile.  While it would be possible
> to allow granularity even to this scale, I don't believe the
> extra complexity would be worthwhile.

I think having separate dependencies is very much worthwhile.
The reason i have the Subversion package split is to give people
choices about their dependencies.  If you don't need Perl or
Python support, don't install p5-subversion or py-subversion.  If
you don't need the bloated Apache network layer, don't install
ap2-subversion.  Subversion 1.1 will introduce the new native FS
fs-backend, allowing subversion-base to lose its most obnoxious
dependency (Berkeley DB 4) to a separate package.

I'd hate not to be able to use your new framework for all this.
If you take this approach at first, do you think it will be easy
to extend it in this direction later?  One way might be changing
your SUBDEPENDS.foo variables to list all dependencies for that
subpackage, with your current proposal handled as:

    SUBDEPENDS.server=	client lib ${DEPENDS}

I will likely look into this at some point.

--  
Eric Gillespie <*> epg@pretzelnet.org