On 1/22/06, Sam Trenholme <sam+centos@xxxxxxxxxxxxxxxxxxxx> wrote:
> >Building from source on an rpm based distro isn't a good idea.
>
> I disagree with this statement. Building from source is something I have
> been doing on RPM-based distros since long before Fedora Core or CentOS
> existed. It's a very old UNIX tradition. Basically, this is why there
> is a /usr/local; the files that are installed from RPMs are in /usr (or
> just the root directory) and programs compiled and installed from source
> are in /usr/local. Almost all programs, when compiled and installed from
> source, will install in /usr/local by default.
You're allowed to disagree. It doesn't make your point right however.
My statement doesn't make me right either. Just because something was
done in the past doesn't make it a tradition, or make it the proper
way to do things. Package management by source sucks. Many source
applications don't allow for 'make uninstall' etc. So you have to dig
by hand to figure out what it put on the system, and dig to remove it
if need be. If you're going to take the time to build from source,
take the time to put it in an rpm.
> The issue, though, is that one shoudn't instll from source to replace a
> program already on their system unless they go to great care to make
> sure the replaced program doesn't step over the already installed program.
> The simplest way to ensure this is to simply remove the RPM install of the
> offending program before installing from source. However, some programs
> have dependencies on the already-installed RPM which you really don't want
> to mess with. The way I work around this is by having my own perl be
> called "perl5.8.7" instead of perl in /usr/local/bin, and having my own
> from-source install of ghostscript called gs-afpl. This way, the newly
> installed program is seen as a completely separate program from the already
> installed program.
Except that it can't really be duplicated reliably system to system,
upgrade to upgrade. There is no changelog for how you built it unless
you take the time to do it, and most people don't. Basically once you
start down this road you're on your own for support. So yes, as a
rule, I stick by my statement of "don't build from source". While it
may work well in limited circumstances, it is NOT something that I
recommend. It's a last resort option. One major reason for this has to
do with RHEL's (and therefore CentOS's) policy of backporting. People
look at a version number and assume it's old or has holes. They don't
know that the fix they want has already been backported and patched
into the current distribution release of the app.
The combination of ignorance (intentional or otherwise) of the
backporting policy and the desire people have to combine
gentoo/solaris/unix logic to a particular distribution leads to
problems. Each distribution has its own way of doing things. Whether
it's deb, emerge, slackpack, or rpm, you should ALWAYS work within the
framework provided by your distribution.
> Installing from source can be done, but care has to be taken when installing
> from source for a package already on your system. I don't install from
> source unless the RPM-based program has a known problem, and the RPM-based
> program is the latest official update. I make sure to change the name of
> the program which I install from source, and always install in /usr/local.
Yes, installing from source can be done. It's quick, but in the end
it's far more time-consuming when things don't go as planned. It's not
tough to write a spec and build an rpm for something, if you REALLY
have to build it yourself.
If it works for you, great. But it's bad advice for a mailing list for
someone who is learning and potentially far less skilled than you.
- Hide quoted text -
--
Jim Perrin
System Architect - UIT
Ft Gordon & US Army Signal Center
