From: Patrick Hartling (patrick_at_[hidden])
Date: 2006-09-08 15:37:18
Dean Michael Berris wrote:
> 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.
>> 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.
I have nothing against Debian or any other Linux distribution (since I'd
rather be using BSD anyway). It's just that, at the moment, I only know how
to make RPMs (and installers for Windows and Mac OS X). :)
> 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 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
Is your packaging of Boost into a .deb package available somewhere? Or do
you have recommendations on how to do it? I would like to learn more about
Debian packaging, and it would be very helpful to have something I could
compare to what we have been doing for Boost.
> 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.
That is what we are doing currently, but we run into problems because our
packaging of Boost is different than what Red Hat is doing. My intention
with this spec file is to have it (or something similar) be included with
Boost so that it is easier for people to do exactly what you are describing.
> 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!
Maybe I am misunderstanding, but I think that you inverted the quoting
above. It appears to me that you attributed David's argument to me and vice
versa. It seems to me that you and I share a lot of goals WRT software
deployment and maintenance.
-- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk