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

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2006-09-08 15:11:11

On 8/15/06, Patrick Hartling <patrick_at_[hidden]> wrote:
> Davide Bolcioni wrote:
> > Patrick Hartling wrote:
> >
> > The point of installing a library as an RPM package is to satisfy the
> > dependencies for other installed packages, not to make it available to a
> > software developer. Similarly, the corresponding development package is
> > intended to facilitate the packaging by making sure that the source code
> > gets compiled against the same set of choices which are embedded in the
> > RPM package found on the destination host, so that saying "Requires:
> > boost" in the .spec file has a good chance of working.
> >
[snipped]
>
> You are right, this is possible. Using package management to deploy
> development packages allows for automation that is not necessarily practical
> when users are putting their dependencies in their home directory on a
> case-by-case basis. Nevertheless, the benefits of allowing parallel
> development package installations is perhaps not something that a lot of
> people want to take advantage of. The real point, however, is that the spec
> file I posted is that a system-wide installation would use the same
> conventions as the one that a user puts in his or her home directory. I am
> used to using Boost in this way, and thus it is my desire to see these
> conventions used in a system-wide installation. Perhaps my uses of Boost are
> atypical, but I like using the fully qualified names.
>

I do not use RedHat based systems much and have a few reservations
against the RPM approach for packaging -- I am a Debian fan needless
to say, but I digress.

As for installing RPM's to satisfy dependencies, that's just one of
the main reasons why you'll want to build a package for a development
library (like boost, ACE, <insert other C++ library here>). Another
reason why you'll want RPM's or "packages" in general is to
standardize more or less the build environment that you are working
in.

In cases where you have different applications building on the same
machine using the same compiler set and libraries, you'd want all the
applications to expect the existence of not only the dependencies
(when you're making packages out of the applications yourself) but
also of a package that can be pulled and installed when that
dependency is not met. In these cases where you have a "build server"
and maybe a "continuous integration environment" on different
(hardware) platforms/architectures and distributions (rpm based, deb
based, and even maybe Gentoo-like build everything), you want to be
able to standardize on the most common installations possible.

Having a package that's made available to the whole system or
installed as part of the (Linux) distribution is definitely a step in
the right direction especially for organizations/enterprises/people
who want to make packages out of the applications they are building.
In our case, we use Debian and we write a set of applications that are
made to work with the stable banch -- we build the Boost 1.33.1
library and package it as a .deb so that we can install the binary
libraries on the stable branch (which is pretty much like backporting,
but we already include Asio and Spirit in the custom Boost .deb we
build). I would imagine (and would like to think) that people who
develop for RedHat based systems would want to be able to roll their
own binary Boost .rpm's for distribution along with their applications
also distributed as .rpm's.

I agree with David on this one, and will look forward to a Boost
provided SPEC file without having to rely on the configurations of
RedHat/Fedora of the Boost library.

Hope this helps!

-- 
Dean Michael C. Berris
C++ Software Architect
Orange and Bronze Software Labs, Ltd. Co.
web: http://software.orangeandbronze.com/
email: dean_at_[hidden]
mobile: [phone]
phone: [phone]
other: [phone]
blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com
http://cplusplus-soup.blogspot.com