On 08/06/2007, at 12:45, Dieter Baron wrote:

>
>> What I'm wondering about also, and related to this, is if we could
>> build different binary packages for subsets of built files.  This
>> could simplify, e.g., the gstreamer packages (and many other packages
>> that are currently split), as the package could build *everything*
>> and then we could easily generate tiny packages for each plugin.
>
>   While this is good for building (official) binary packages, we would
> still need to be able to build only a subset for users building from
> source.

Indeed.  Until we have decent binary packages so that users don't  
have to mess with rebuilds ;-)  But that day seems to be veeeery far  
away.

>   Also, how do we maintain what files go into which package?  Manually
> updating some kind of PLIST annotation on each update sounds bad.

I can't think of any other way except for "automated" subpackaging  
(which could be applied to libraries, for example) where you can  
predict which files belong to each package.

>> This could also be useful to easily split packages providing
>> libraries into run-time only files (the .so's) and the headers, as
>> almost any Linux distribution does.
>
>   I don't see the big benefit in that (and it's something that has
> annoyed me no end on linux hosts).  Header files don't take up much
> space.

But they are "ugly" in a production box where you don't want any  
compiler-related stuff to be available, for example.  Anyway, this is  
just a specific use case of this functionality.

I'm sure many, many, many other packages could use it.  For example,  
some libraries (glib2, to take a popular one) also come with programs  
(either sample ones or build-related utilities) that get installed  
along them.  This is bad in many cases because these programs  
introduce additional dependencies that aren't really needed for the  
library itself nor at run-time for any program that uses them.  These  
end up polluting the dependency tree and make further updates a lot  
more complex than they'd be otherwise.  Taking glib2 again, this  
pulls in perl (required at run time too!) but perl is not required  
for most programs that use glib2.

-- 
Julio M. Merino Vidal <jmerino@ac.upc.edu>