Subject: Re: emacs22
To: Dieter Baron <email@example.com>
From: Julio M. Merino Vidal <firstname.lastname@example.org>
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
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
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 <email@example.com>