On Fri, Jun 08, 2007 at 12:31:36PM +0200, Julio M. Merino Vidal wrote:
> On 08/06/2007, at 12:14, Dieter Baron wrote:
> 
> >  Because having separate packages for different build options does
> >not scale well and is hard to maintain.
> >
> >  What we should do is specify which option combinations are important
> >enough so we want binary packages for them and then build all of those
> >during a bulk build.
> >
> >  Joerg's new bulk build framework supports building multiple versions
> >of a package from one package directory.  So we would need a way to
> >specify option combinations (and have the bulk build framework pick
> >that up) and a way to name the resulting binary packages.
> >
> >  Maybe something like PKG_OPTIONS_BINTAGS that is a list of tags for
> >binary packages to build from this directory (binary packages will be
> >named PKGBASE-TAG-VERSION.tgz) and PKG_OPTIONS_BIN.tag that lists the
> >options setting.  In additionto the tags, a binary package with the
> >suggested options is built, called PKGBASE-VERSION.tgz.
> 
> That's sounds good enough, but until it is put in use... we should  
> stick to the "old" way of doing things (at least for emacs I'd say).

  Leaving the packages that are already done in the old way until the
new way works sounds reasonable.

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

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

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

					yours,
					dillo