[PLUG] On the topic of distributions

Jeme A Brelin jeme at brelin.net
Thu Jan 23 01:39:02 UTC 2003


On Wed, 22 Jan 2003, Rich Shepard wrote:
>   If I understand the concept of packages (and I don't care whose they
> are), they make installation, upgrade and removal of an application
> easier and quicker by tracking the libraries upon which the
> application depends and notifying the user if those libraries are not
> present. If my understanding is correct, how do users of non-package
> distributions (e.g., Slackware) cope with dependencies when a new
> application (or an upgraded one) is installed from source?

I guess I don't understand this question.

My desktop machine is built entirely from source by hand (without
automated installation programs or scripts like Gentoo or whatever
has).  It has never had any kind of package management system on it.

A package, to me, is a source tarball from the maintainer's public
archive.  I download it, uncompress it and untar it, then run the
configure script with the --help option to see what it can do.

If there are dependencies that aren't met, the output of the configure
script should tell me.  Either a feature will be disabled because a
library isn't found or the configure will come to a dead stop because a
necessary requirement is not present.  The configure script will usually
let you know what the minimum compatible version should be as well.

As another poster noted, the interdependencies aren't quite as strict with
software built from source because the binaries are constructed using
whatever libraries you've got on hand.  When you upgrade lopster or
something, you're getting a precompiled binary that was built against a
very specific set of libraries and so you need to have dependent binaries
that exactly match those of the packager.  When I upgrade lopster, it just
links against what I've got so long as the functions are present.

>   I get notices from Red Hat when they have a package upgrade
> available that welds shut a security hole in the existing package.
> This is a rather handy tool for a non-SysAdmin like me who can't spend
> a lot of time each day reading bug-tracking mail lists and other such
> sources to learn of vulnerabilities removed. What do folks do to keep
> their systems secure when the distribution they run is Slackware,
> gentoo, linux-from-scratch or something else?

Well, Slackware and Gentoo have distribution maintainers who keep on top
of those things.  Gentoo has a ports tree that is kept up-to-date with
relevant patches and so on.

For my desktop system (and, I assume, systems built using the LFS book),
I'm pretty much on my own.  I keep on top of important updates as much as
I can.  However, it's just my desktop system and it's not running any
services that are accessible through my firewall.

In my opinion, this is the one very positive feature of package management
systems.  I have had to maintain non-package-managed machines that were
running live services with active internet connections and it is no
feast.  All of my public servers (except one, which runs just a handful of
services that are fairly rigorously maintained) are Debian for this
reason.

My desktop machine ISN'T Debian because I am often playing with software
outside the maintainers' stable trees and don't want to have to build
*-dev packages for every weird library to keep my dpkg databse current and
functional.  Someday, I'll figure out how to easily do that and just
maintain my own apt source for bleeding edge packages.  Right now, it's
more effort than it's worth.

> In a non-critical way, I'm curious if a lot of the Red Hat x.0 (and
> sometimes, x.1) bugginess is an unintended consequence of complexity
> from wrapping tools in covers that make them easier for us
> less-technically-sophisticated users?

I think Fedor nailed this with x.0 vs X.Y(Y>0) distinctions.

I've never run Red Hat for many reasons.

> I would like to understand a bit better what's behind a lot of the
> tools I've taken for granted for the past 4.5 years.

If you want to learn, the very best thing you can do is throw some old
hardware together and build a system from scratch.  You'll "get it" after
you've got a full working system with all the software you normally use
built, installed, and configured.

I'm serious.  It's a great learning experience.

> I hope y'all can help increase my knowledge and understanding without
> condemning any given vendor or the folks who use the results of their
> efforts.

Oh, and commercial software sucks.

J.
-- 
   -----------------
     Jeme A Brelin
    jeme at brelin.net
   -----------------
 [cc] counter-copyright
 http://www.openlaw.org





More information about the PLUG mailing list