On 8/15/06, Patrick Hartling <patrick@137.org> 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@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com