ALFS/LSB...LSB, your thoughs

Mark Stone mstone at
Fri Jul 7 12:27:57 PDT 2000

On Wed, 28 Jun 2000, Jesse Tie Ten Quee wrote:

> Just curious about yours thoughs on ALFS/LFS and the LSB.
> Bryan Dumm and i have started working on a basic system that ALFS can be
> based off. which will be posted to alfs-discuss at once we
> get it to a point where we like it.
> You seemed to have a great 'vision' if you can, call it that of what ALFS
> could do with LSB, i'm just curious if your going to explain what you were
> thinking at the time... dunno
I have a couple of different concerns that come together in the ALFS

The main concern is this: LSB is just a specification; in and of itself it
does not provide a working system that vendors can test their software
against. For companies deeply emersed in Linux, this isn't a problem: they
can look at a Linux installation and figure out, more or less, whether or
not it's LSB compliant. But these aren't the companies I worry about. I
worry much more about companies like Oracle and Informix, that want to
play in the Linux space, but don't necessarily understand Linux all that
well. For them to get value from the LSB, there has to be an LSB-compliant
system they can test against. ALFS could be that system.

LFS alone can't be, because it isn't automated. No one at Oracle is going
to grow through a Linux install by hand. They want a CD they can pop into
a machine, a few simple questions they can answer, and presto: they've got
an LSB-compliant Linux system they can test aginst.

Sounds like a distribution, right? Not really. To me a distribution means
a lot of things: installation scripts, package management systems, and
most importantly an end result that may include binaries only of many
packages. There's also the commercial/political baggage that comes with a
distribution. Every distribution has an agenda, even Debian. None is
trying to be just Linux, plain and simple.

So ALFS can and probably should have installation scripts, even a package
management scheme, but can be distinctive by (1) making sure that every
ALFS system has source, and has binaries compiled from source on that
system, (2) being truly vendor neutral, and (3) being LSB-compliant. That
combination has the potential to be really compelling to companies like
Oracle and IBM.

What about package management? This is a complicated question, but one
that needs to be addressed. Let me start by commenting on RPM. People tend
to assume that RPM means Red Hat, and that distributions like SuSE and
Caldera are just Red Hat variants because they use RPM. But people forget
RPM's origins.

The original specification for RPM is Marc Ewing's doctoral dissertation
at Carnegie Mellon. It's a general solution for a general problem: package
management. You can use RPM any way you want. You could use it as a
document management tool, or a version control tool. You could port it to
Windows and use it as an installer/manager there. None of these
possibilities have anything specific to do with Red Hat.

Someone managing a Linux system wants to know about dependencies, and
wants a map of what software has been installed on the system. RPM
provides a tool that can be used for that. Nothing about RPM requires one
to use it the way Red Hat does.

The same is true of dpkg. It's just a tool; you don't have to use it to
build a Debian system. You can use it for whatever you want.

So the bottom line is that ALFS should have some way of easily presenting
what software has been installed on the system, and what dependencies
there are. Having gone that far, it makes sense to include some capability
for automating the installation of new software. The key difference with
traditional package management tools is that you want a system that will
actually compile new software from source, rather than install a
pre-compiled binary. But I think that capability exists within RPM and

So you might want to use RPM, or dpkg, or both, but use them in a way
appropriate to ALFS. Or you might want to build a new tool. But you have
to do something.

One question I've been thinking about a lot in recent weeks is this: how
do things work in the FreeBSD world? I know they have a package manager,
and I know that nobody seems to gripe about it as much as people gripe
about RPM. But I don't know how it works, what the conventions are about
where software gets installed on a FreeBSD system, how those conventions
differ from Linux, and whether it would be reasonable or even possible to
consider porting FreeBSD's package manager to Linux.

So those are some of my thoughts, and some of my questions. Let me know
what you guys think.


 Mark Stone                                         VA Linux Systems
 mstone at                        Publisher, VA Media Group
 (408)542-5745          Editor-in-Chief, Journal of Linux Technology

Mail archive:
IRC access: server: port: 6667 channel: #LFS
Unsubscribe: email alfs-discuss-request at and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)

More information about the alfs-discuss mailing list