On Tue, 14 Nov 2000, TAKEMURA Shin wrote:
>  > 	tar bla.tgz bin/* share/* ...
> 
> I agree with you. The pattern matching approach is useful in many
> cases. But I don't think it not work well in all cases. I believe 
> that there are some cases in which we have some problem.
> 
> For example, 
>   - core executable binary might need some files in lib/ directory.
>   - shared obkects and static link libraries will be in same directory.
>   - What shoud we do about @exec and @unexec directive?
>   - Some packages have a install script in it. They might fail if some
>     files were deleted implicitly.
>   etc.
> 
> My point is, 
> 
>   It's better that you can describe the rule to choose files of the 
>   subsets if you need or you want.

Indeed. 

Having thought a bit more about this thing myself, I'm more and more
convinced that we'd rather not do this, and keep packages really
seperate. If there's several functionalities wanted, we should have two
packages. That way people sure know what they have installed when they
look at the package name - something they can't be with subpackages. 

Another area that I imagine problems approaching are the whole dependency
system. Your proposal doesn't include that, and frankly, I don't think it
can without opening a major can or worms. (like: think of when all but a
needed subpackage is installed. what do you do to install only a
subpackage from source?) 

In short, I'd rather see our packages split properly where it's
appropriate.

To make things easier, creating several (binary) packages from one
installation might be doable (like RPM has): you install a shared and a
static lib in one "make install", and end up with two packages registerred
and tarred up. I think code for this can also be found in OpenBSD - check
out their bsd.ports.mk for MULTI_PACKAGES/SUBPACKAGE (used e.g. to build
pine and pico in one run, check out their ports/mail/pine).

IMHO that's the way to go in this case.


 - Hubert

-- 
Hubert Feyrer <hubert@feyrer.de>