[CONSPIRE] Installing software from source on Linux?

[Rick Moen]

Quoting Dan Bikle (dan.bikle at gmail.com):

> I was just handed the root password to my server running Linux whitebox 4.

Just to fill in the peanut gallery, Whitebox Enterprise Linux v. 4 is an
"RHEL rebuild", i.e., one of maybe a dozen open source recompiles of Red
Hat Enterprise Linux with Red Hat, Inc.'s trademark-encumbered images
and other "branding" files replaced with generic replacements.  It's
published by exactly _one_ maintainer, John Morris of Beauregard Parish
Public Library, DeRidder, Louisiana, who says he performs the
maintenance entirely for his employer's benefit, but certainly doesn't
mind that other people find it useful, too.

For the record, not that you asked, but my own view is that that
sole-maintainer aspect of Whitebox is a bit worrisome (and the same
problem exists with another semi-popular RHEL rebuild, David Parsley's
"Tao Linux").  Personally, I tend to steer people interested in RHEL
rebuilds towards CentOS, instead, because there's a broad-based
community behind it.  (Disclosure:  I'm friends with several of the key 
CentOS people -- but, hey, Linux development is a notoriously tight
little world).

Why an RHEL rebuild?  Many people who admire Red Hat Enterprise Linux 
are leery of RH, Inc.'s service agreement and associated fees,
especially sites with a large number of machines such as compute
clusters.  On the other hand, Red Hat's a good company that's worth 
throwing some support to, if only because it employs a large number of
important coders.

Mind you, Dan, I'm not trying to convince you to rebuild your server(!).
I just wanted to fill you (and others) in on a bit of background.  In my
experience, a lot of the sites running Whitebox picked it because
someone was familiar with Red Hat from the pre-Enterprise days when 
Red Hat ISOs (CD images) were freely downloadable, but didn't want to
pay RHEL prices.  Whitebox happens to be the first and best-known RHEL
rebuild, but (in my view) not one of the more desirable ones.



Anyhow, I see that Dan Martinez gave you a partial answer.  (Thanks,
Dan!)  I wanted to start out from a different angle, that of politely 
inquiring about whether we're solving the right problem.  (Please don't
take offence!)

You wrote:

[describes a variant of the standard ./configure ; make ; make install 
drill.  And them then mentions that, on OS X:]

> I've found a utility-website (http://darwinports.org/) which wraps the
> above sequence with a nice command called 'port'.
[...]
> So, does Linux have anything like this 'port' utility?

Implicitly, you mean on Whitebox, which for most purposes is
indistinguishable from all other Red Hat variants.  As such, it's
principally designed for convenient and easy installation and removal of
packages (*.rpm files) containing _already compiled_ software, including
automated handling of dependencies.

I just noticed that Daniel Gimpelevich has weighed in:  Yes, "yum" and
its handy little front-end tool, "yumex", are the right tool for
managing precompiled binary packaged software on Whitebox or any similar
distribution of the Red Hat family.

There are other families of Linux distributions, including a number
(Gentoo Linux, Source Mage, Lunar Linux, Sorcerer, ROCK Linux, about
five or six others[1]) designed to automatically build from source code,
with automatic satisfying of dependencies, any softwaare package you
decide to install.

> I'd like to get skilled at installing software from source.

And this is the point I was getting at, above:  Are you sure this is the
problem you really want to solve?  There's nothing wrong with wanting to
install software from source code; many people on both the BSDs and
Linux make a point of operating regimes that do so by preference as the
primary way of installing and removing software.  My point is that
Whitebox (like others of the Red Hat family) is not well designed to do
so by default.

I'm one of a relative few old-timers who started out on early BSD
(386BSD), left for early Linux, and mostly stayed there out of
preference, in part because it became practical and easy to -not-
compile most of one's software:  Even with good build frameworks like
Jordan Hubbard's "ports" system for FreeBSD (after which the Darwinports
"ports" command is obviously based), in my experience you not only had
to sit on your heels through long compile sequences but also somewhat
frequently (but unpredictably) had mysterious build failures in some
parts of the ports tree and had to fall back on the alternative
precompiled packages, anyway.

Differences of opinion are what make horse races, and legions of Gentoo
Linux and BSD ports people differ with me on this, but in my personal
view the days of routinely compiling new software from source, even with
autobuild frameworks, was the bad old days.  ;->


Every BSD or Linux distribution (including OS X) has its own
characteristic way that _it_ is designed to do things by default, and
can be wrestled into doing things some other way but only at the cost of 
considerable extra effort.  Which begs the question:  If you're put in
charge of a Whitebox or other Red Hat-family distribution, how do you
administer software in the natural way that _it_ is designed to
implement, and still accomplish everything you want to do?  Similar
questions apply to all other BSD or Linux families:  Each has
characteristic quirks and tricks that you pick up, as you become
familiar with it and learn how to get things done without "fighting" the
system.

Let me give you a for-instance, from my own experience:  Like Dan M.,
I'm mostly gone from the Red Hat-family space.  (No offence intended to
partisans of that sort of system.)  My preferred software drug of
choice, for the last eight years or so, has been the Debian family of
systems, which Daniel G. mentioned in his post, which has a very smoothly
functioning, minimal-maintenance software handling regime based
primarily on precompiled binary *.deb packages.  (The same tools, oddly
enough, will also support autobuilding of new software from source in a
fashion eerily reminiscent of the BSD ports system, but that mode of
operation is not as well developed or as widely used.)

In an earlier incarnation of my server, when I was less familiar with
the ins and outs of Debian's package regime, someone working with me
built a number of key pieces (mostly glue code supporting the
interaction between Python, PHP, MySQL, and Apache httpd) from source
code, iteratively doing the dance you describe:

./configure
make
make install

(Typically, if you don't supply a "--prefix" directive to autoconf, the
default installation destination prefix is /usr/local, which is in my
view ideal for locally installed software and should not be fooled
with.)

...And the glue code worked just great -- right up until about the
second or third round of major maintenance, at which time things started
to break.  Why?  Because Debian's package regime wasn't aware of the
glue code's existence, and therefore could not take its dependencies and
other needs into account during subsequent removal and installation of
other software.  E.g.:  Some of the glue code relied on modules locally
installed when my helper locally installed Python 2.1 from source code?
Oops!  The glue code broke badly when I rebuilt but didn't know about
that dependency.  Some glue code relied on a packaged release of Perl?
Oops!  It broke when the Debian package system purged that release, not
knowing that something locally installed relied on it.  (Those examples
are not exactly what happened, but it was on that order.)

As soon as I realised what had happened, I set about reconstructing what
pieces had been locally installed from source tarballs, and found upon
examination that _all_ of the pieces were actually available in
precompiled *.deb package form, but my helper simply hadn't known their
names and so had been unaware of the possibility.  Ever since purging
the local pieces entirely and replacing them with the *.deb equivalents,
my server system has autoupgraded smoothly, over the several years since
that time, with the zero downtime and almost nil effort that Debian is
famous for.

My only locally installed package remaining is the leafnode beta to
support local NNTP newsgroups, necessary because the preceding full
release (available as a *.deb precompiled package) still lacks the local
newsgroup feature -- or did when I last checked.


That's a roundabout way of making the point that you, with your Whitebox
system, might want to study up on the characteristic Red Hattish way of
maintaining _that_ system, before embarking on any sort of source-based
software installation in parallel to Whitebox's own rpm-based
software-tracking regime, which risks "fighting the system" in the sense
I've attempted to describe.

You would learn about yum and yumex.  You'd learn about third-party
*.rpm repositories such as "dag" and fedoralegacy, and the rpmfind.net
Web site / search engine.  You could probably come right back here and
teach me a lot about that subject, because I'm a bit rusty on that
subject (and, well, not enthusiastic about going back there, as it's
just not my cuppa).


And in the end, as Daniel G. said, you _might_ end up deciding that
you'd be happier with Gentoo Linux or FreeBSD (or Sourcemage, Lunar 
Linux...), if you really, really prefer a good source-based software
regime for your system.  But I _absolutely_ understand why you'd be
reluctant to blow things away and rebuild.


On the other hand, if you clarify that, yes, you really _do_ intend to
address the problem of finding a good source-based autobuild framework
(are sure that's the right question), and are sure you wish to do this
on Red Hattish Whitebox, even though doing so cuts against the grain of
that distribution's characteristic way of doing things, I'm game for
looking around for something analagous to the Darwinports "ports"
command, for you.  But please do confirm that you're sure you want to do
that, before I do.  

Thanks, and my apologies for length.  I hope this explanation is of use
to you.  (And welcome to CABAL's "conspire" mailing list, by the way.
Ruby rules!  ;->  )


[1] http://distrowatch.com/search.php?category=Source-based&origin=All&basedon=All&desktop=All&architecture=All&status=Active

-- 
Cheers,
Rick Moen                      "vi is my shepherd; I shall not font."
rick at linuxmafia.com                               -- Psalm 0.1 beta