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

From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-09-20 14:25:19

Rene Rivera wrote:
> I know I'm quoting most of the original message... But this is a ping. 
> Patrick you there?

Oops, I completely dropped the ball on this. Thanks for the ping. See my
responses below.

> Rene Rivera was being inquisitive:
>> Patrick Hartling wrote:
>>> The spec file that I posted does the following:
>>>
>>>    * Provides compatibility with (current) Red Hat conventions using
>>>      optional "-symlink" packages, the use of which would conflict with
>>>      Boost RPMs provided by Red Hat and would prevent the ability to
>>>      install multiple boost-devel RPMs in parallel
>> Are those different from the synlinks the "bjam install" does?

Yes. The boost and boost-devel RPMs that get created are intended to look
just like the results of "bjam install". The additional boost-symlinks and
boost-devel-symlinks are add ons (more or less) intended to make the
installation appear as it does now with the RPM distributed by Red Hat.

>> Does your 
>> RPM put in the symlinks "bjam install" produces?

Yes.

>>> Basically, the spec file that I posted follows what I understand to be the
>>> "normal" way of installing Boost. In other words, the boost and boost-devel
>>> RPMs created by this spec file provide a Boost installation as it would look
>>> after running 'bjam install --prefix=/usr'.
>>>
>>> Are there other thoughts on this topic other than what was discussed
>>> previously on this thread (much of which is below), or is this approach to
>>> installing Boost not how people normally want to operate on Linux?
>> I personally like it, but then again I came up with the current install 
>> scheme, so I'm biased :-) A few future and integration questions...
>>
>> Have you tried packaging the 1.34 branch?

No, not yet. I can give it a try.

>> Is it buildable if one doesn't have admin privileges? I'm asking because 
>> making the RPM during a release cycle would be much easier if we can use 
>> the SF compile farm machines instead of relying on personal setups.

Yes, you just have to have a ~/.rpmmacros file that sets %_topdir to a tree
where you have write access. Mine looks like this:

%_topdir /home/patrick/rpm

Under rpm, there are the directories BUILD, RPMS, SOURCES, SPECS, and SRPMS.
I put my .spec file in rpm/SPECS and the Boost source in rpm/SOURCES and run
'rpmbuild -ba boost.spec'.

>> It's been suggested a few times that we should move Boost towards a 
>> non-monolithic distribution model. Which means that we would want to 
>> have individual RPMs for the various libraries. Which I guess also means 
>> that a top level Boost RPM would be only a reference to the other 
>> version specific RPMs for the libraries. Now...
>>
>> Do you see any problems that your RPM would create if we do move in that 
>> direction?

Not strictly, but I don't have experience with making a top-level RPM as you
have described. It wouldn't be too much work to make a bunch of subpackages
within the boost.spec file that I posted. I have already done that for
another project. It makes the spec file more complicated, but having a
monolithic RPM for this particular software didn't make sense.

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.

>> If Boost does provide an RPM, we would need someone to actively maintain 
>> it. Are you volunteering yourself to do this maintenance?

Yes.

>> Note, it would 
>> not just be editing the RPM script(s) but also witting documentation, 
>> specifically for the release manager to use in building the RPMs.

No problem. I've written a lot of documentation, and believe it or not, I
normally enjoy doing so. :)

 -Patrick

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