Re: [boost] Boost RPM spec file: Take 2

From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-09-27 09:03:18

Pedro Lamarão wrote:
> Patrick Hartling escreveu:
> 
>> What could get complicated is dealing with optional libraries and the like.
>> In my experience, it can get tricky to put conditional stuff into a spec
>> file, mainly because rpmbuild needs to know which sub-packages to handle
>> after the build completes and which ones to skip. If that can't be
>> determined statically when rpmbuild gets started (before any source
>> extraction or build takes place), then I don't know how to handle that case.
>> That doesn't mean that it's impossible, and I am quite new to writing RPM
>> spec files. Others may have insight into this sort of situation.
> 
> The point of a non-monolithic set of RPM files is not to conditionally 
> build packages, but to conditionally install them.

I understand that, but the RPM spec file has to know what packages to create
and what files go in those packages. The rpmbuild command will fail if there
are unpackaged files or if an attempt is made to include a non-existent file
(in other words, a shared library that didn't get built for whatever reason)
in a package. Hence, it is critical for the RPM spec file to know what is
being compiled and what isn't. One way of handling this would be to have a
spec file for each library instead of having one that builds everything at
once and then packages things up into multiple .rpm files.

> This enables other packages to describe their dependencies in a more 
> granular way. Suppose someone wants to install a new cron substitute 
> based on DateTime. This person doesn't care about Boost. It's ideal for 
> her to install only DateTime, and keep things to a minimum.

Yes, and I would be happy to see Boost packaged up this way.

> Typically, pre-built packages will live in a repository somewhere, 
> available to interested people that should be installing them through 
> some package dependency resolver like yum or apt.

Right.

> The particular complication in this case is determining the 
> inter-dependencies in the Boost collection. It may be that the goodness 
> of the non-monolithic design will be made nil by the extreme 
> interconnection of all the libraries. I can't tell.

I have no idea, but it would definitely be interesting to see how that pans
out. How would header files not associated with a compiled library be
packaged? Would there be a boost-base package, or would the header-only
libraries need to be partitioned up, too?

 -Patrick

-- 
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/