Subject: Re: emacs22
To: Dieter Baron <>
From: Julio M. Merino Vidal <>
List: tech-pkg
Date: 06/08/2007 13:17:40
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  

>   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 <>