[conspire] Why to use packages if you can -- and reasons you might not

[Rick Moen]

Of possible interest.

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Fri, 14 Jan 2005 15:46:34 -0800
From: Rick Moen <rick at linuxmafia.com>
To: "Barton L. Phillips" <barton at applitec.com>
Subject: Re: Afterthought about user "education"

Quoting Barton L. Phillips (barton at applitec.com):

> What are your thoughts on source packages? I have had to use several 
> source packages that just didn't seem to be available as binary.

Here's a hypothetical case of program workflow.  Upstream
programmer/maintainer Alice creates nifty utility foo for *ixes, and
releases it under an open-source licence.  She carries tarballs on her
ftp site, and puts out new releases there.  Bob is a package maintainer
for hypothetical Linux distribution Barlinux.  Barlinux makes available
to its users not only upstream pristine sources, such as
foo-1.1-orig.tar.gz, but also its custom-modified binary and source
packages for Barlinux, such as foo-1.1-src.bar and foo-1.1-i386.bar .

In taking on this role, Bob assumes several obligations:

1.  To make damned sure that whatever he packages is really Alice's 
    work, rather than a trojaned imitation that someone snuck into
    her ftp directory after site-compromising her ftp server.[1]
2.  To base his package on the release of foo that's best _suited_ to 
    Barlinux's users:  It may be that Alice's latest releases are 
    pretty wild efforts to shake out bugs in new features[2], and
    Bob's better choice is a few revisions back along Alice's 
    trail of CVS tags, etc.
3.  To apply any needed security fixes.  Sometimes, if Bob is using 
    a slightly older one of Alice's releases as his base, he may have
    to backport patches. 
4.  To patch Alice's work to make the Barlinux package of foo 
    comply with Linux standards and Barlinux policies.  For example,
    Alice might be an unreconstructed SunOS geek and blithely dump 
    some of foo's libs into /etc, etc., or otherwise do things that 
    are regarded as Just Plain Wrong on Barlinux or on Linux generally.  
5.  To generally serve as a last-gasp quality check on what Alice is 
    doing.  I mean, after all, Alice could have gone rogue and put 
    some incredibly nasty routine into her code, or someone could have
    stolen her SSH credentials for the CVS repository, etc.  From
    this perspective, it's _nice_ that there's a lag between Alice
    releasing new stuff and it getting packaged and released for 
    end-site sysadmins to install.
6.  To do the work to ensure that foo installations on Barlinux 
    get properly registered into Barlinux hosts' package databases, 
    i.e., the _obvious_ work of a package maintainer.

What you're describing, above, is one of the scenarios where one might
consider sidestepping Bob (or being obliged to do so), and instead go
directly to Alice's upstream release.  E.g.:

o  Bob doesn't exist.  (There's no package for your distro.)
o  Bob's work sucks.
o  You really, really want a newer version than Bob has released.
o  You have local needs for which Bob's package is unsuited, or 
   suboptimal.  Like maybe you're on AMD64 and want to compile for 64-bit,
   or you want it compiled without spurious GNOME lib dependencies, etc.

If there's no Bob (the scenario you mentioned), then you're sorta stuck:
Given that you want to install foo, you might have to go with compiling
foo-1.1.tar.gz from source (into /usr/local, please!) -- with or without
doing the work to make it register in your package database.  However,
some Bob-type advantages are compelling enough that you might consider 
looking for some similar distro's foo-1.1-src.theirformat or
foo-1.1-i386.theirformat file, and using that instead.  You might even 
be able to convert directly to your package format, e.g., using Joey
Hess's "alien" utility, which converts among rpm, deb, Stampede, and
Slackware formats.

If there _is_ a Bob, but you're for one reason or another not happy with
his binary package, you still might consider using foo-1.1-src.bar as
your starting point.  Then, compile and optionally modify _that_, 
instead of Alice's upstream tarball.

In any event, you shouldn't ignore Bob's work without a damned good
reason, and should be really, really careful if you're obliged to 
do without that work.  It's crazy to be a "emergency holographic"
package maintainer if you don't have to.


> I use RedHat and Fedora mostly and would like a way to somehow insert
> the source compiled stuff into the rpm database. I suppose I could
> build an rpm and then install from that but it seems like a lot of
> work most of the time. Does Debian have a way to do this, that just
> might make me try it a bit more (I do use Knoppix a lot which is
> Debian).

Yes, there are some tools for Debian and Debian-derived distros to 
help casual creators of packages.  Please see the Developer Resources 
section on this page:  "Information" on http://linuxmafia.com/kb/Debian/

You'll have to try 'em for yourself, since I really don't know them
well.

[1] This isn't just a theoretical concern:  Several trojaned source
tarballs of *ix utilities have been sneaked onto compromised ftp sites
over the years.  Please see comments in my EBLUG talk slides from late 
last year:  http://linuxmafia.com/presentations/

[2] Like, for example, when OpenSSH was urging privilege separation on
everyone, but most distributions were sticking to older versions that 
lacked that feature, and continually backporting fixes from the new 
releases.  Or:  The majority of distributions that still ship
old-reliable Apache 1.3.x, despite the fact that Apache Foundation 
says it's unmaintained and wants everyone to switch to 2.x.


----- End forwarded message -----