Re: [linux-audio-dev] ardour Q

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ardour Q
From: Will Benton (willb_AT_cs.wisc.edu)
Date: Fri Jul 20 2001 - 01:06:42 EEST


> Please, would people stop using RPM's or any package system for that
> matter to install libraries that they need to use with applications
> that they have to compile from source? It causes so many problems. If
> you are building a tool from source and it needs library X, I
> energetically encourage you to fetch and install library X as a source
> tarball. This will ensure several things:

I will agree with what I am reading as your main point (it is dumb to
blindly install packaged libraries), but would like to respectfully
disagree with you on your solution to the problem. I believe that the
proper way to handle RPMs of libraries (especially c++ ones, where build
environment makes all the difference) is to build the RPM on your own
system and then install it. RPM makes this mind-numbingly easy -- just
use "rpm --rebuild foo.src.rpm". This will avoid the headaches caused
down the road if one installs stuff behind a package manager's back.

NB: I realize that the merits of packaging systems are a major holy war
topic. I am not trying to start one.

<tongue-in-cheek response>
Please, would people stop building libraries or binaries from source on
a package-based system? It causes so many problems. If you are
building a tool from source and it needs library X, I energetically
encourage you to take the fifteen minutes to make RPMs of both the
library and the tool. This will ensure several things:

   1. That you really have all of the prerequisites for the library and
that anyone else who uses this package (maybe you on a different
computer) also has all of the prereqs. RPM does a fairly good ldd-style
analysis of packaged binaries, and uses this information to generate
dependencies.
   2. That when it is time to upgrade library X, your system will let
you know how many applications you are breaking -- then it is a simple
matter of "rpm --rebuild" or "rpm -bb" to update your tools. Otherwise,
you will have a frustrating time gathering sources, re-patching them and
re-building them, as you discover that the apps are broken.
   3. That if you need to install another tool which depends on library
X, you can do it because RPM knows that you have library X installed.
   4. Building source and binary RPMs guarantees that you have a
structured way to install, rebuild, and remove your software, with a
well-designed system doing the bookkeeping for you. Installing
everything from source on a package-based system is inviting a
cluttered, unmaintainable mess of dependencies.

RPMs are a great way to install everything -- but *binary* RPMs can be a
headache, especially for c++ code. When in doubt, build your own binary
packages using a source RPM or spec file, and avoid the PITA.
</tongue-in-cheek response>

Seriously, I have had no .so problems since I began following this
approach, and I have source RPMs and spec files that have gracefully
migrated with me over the last two-and-a-half years. Seven years ago,
when I used Slackware, I had a major pain with all of my local apps when
I upgraded my distribution -- no more. If you don't want to use
packages, you shouldn't use a package-based distribution. (Perhaps a
self-contained /usr/local is also a solution, but that doesn't address
concern #2.)

best,
wb


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Jul 20 2001 - 01:07:49 EEST