Some thoughts

John Schmerge schmerge at speakeasy.net
Wed Jun 13 21:23:45 PDT 2001


Hi everyone,

For all of you who haven't spoken to me on irc, I am a fairly long time
lfs'er and a relative newbie to the alfs system. The ALFS system is something
very similar to a project I was thinking of starting before I knew of ALFS's
existance. Consequently, I wish ethusiastically to get involved with the
ALFS project and offer any services that I can.

  Having gotten the smaltz out of the way, I would like to provide a couple
suggestions about things that we consider as we move forward and also my
viewpoint on many of the ideas put forward on the lfs-discuss mailing list
in the past day or two...

  First, let me explain my vision on what the ALFS project could become. Let me
also forwarn those that read this message that the direction I think ALFS should
head may be very different from the consesus of opinions of the prominent ALFS
developers thus far.

  I envision ALFS becoming another Linux distribution with several unique and
powerful features. Most notable of these features is the idea of package
management at the source-code level, not the binary level, like the RedHat or
Debian systems. This allows an ALFS system to provide functionality very
similar to that provided by the *BSD ports system; I will comment more about
the *BSD ports idea later in this message, so please hold off any criticism
until after you read further. Other notable features that I see being very
valuable are using the ALFS as a system administration tool and also as a
sophisticated testing tool for LFS book releases.

  Now that I have explained my thoughts as to where ALFS should go, let me
start speaking of details...

  The first thoughts I had yesterday when reading the 'Moving On' thread on the
mailing list contrasted greatly with many peoples opinions. I wanted to hold
off posting my thoughts until I had time to collect them and provide them in
a cohesive message.

  The main things that I think are important to consider in revisting the
design of ALFS are as follows:

0. How simple is the system? More complexity == more problems. While not the
   most important constraint, this is something that we need keep in the back
   of our minds as we proceed. Another facet of this issue is that we will
   want to minimize, if not eliminate, the ammount of software a user has to
   install to get ALFS up and running.

1. The ALFS system should be as independent of other software as is possible.
   The rational I have for this is as follows: no one can anticipate all the
   possible permutations of various compilers, libraries and linux
   distributions that people may be using to bootstrap an ALFS install.

2. ALFS should be able to function with or without optitional packages. This
   will require us to draw a line in the sand which will define what is
   considered to be optional. While most will think that this will be a fairly
   black and white issue, I beg to differ; it is easy to say 'optional packages'
   are anything not included in the book, the software that the book itself
   provides is not enough to run an ALFS system, especially if we decide to
   use a language like Java or Python.

3. ALFS should provide an easy upgrade path. This is something that does not
   currently exist. The decision of how to provide this functionality profoundly
   impacts the overall system design, for decisions that we make regarding this
   issue impacts such things as how we need to bundle into the XML profiles
   information about inter-package dependencies. This issue is a rabbit hole
   that would be better to stumble down now rather than in three months when
   it will require us to do a tremendous ammount of redesign.

4. The communication between the front end and back end will need to be settled
   on before we go anywhere. The establishment of a communications protocol
   that is easily extendable between the front and back end will allow
   simultaneous development of the two pieces of the system. This issue
   includes such loaded questions as how to provide distributed system
   management.

5. We need to take a look at the *BSD ports collection and avoid the pitfalls
   that it suffers. I personally have some major issues with BSD's ports,
   specifically that they do not offer a way to customize the package being
   built and rarely build without work.

6. In order to provide some of the more powerful RPM-like system administration
   features, we're going to have to provide the functionality in the back-end.
   This is another set of decisions to make.

I know that some of these issues at have partial to complete solutions now,
however it cannot hurt to revisit them and think about how easily the current
implementation will be extended to provide the functionality that will
eventually be necessary to have a polished system that competes with other
systems and provides what we all wish.

  To this end, here are several suggestions that I have. First, since the
backend will need to run on any and every linux distro, our choice of languages
is very limited; the only things that we can count on are having a shell and
the ability to run binaries. Since I do not believe anyone would wish to
develop in Bourne shell, I think the only choice we really have is C or C++
(unless people wish to use Ada :). If we choose to use C++, then care will
have to be taken to make sure that we use only features of the language that
have been stable since egcs 2.91.x. This may seem restrictive, however it will
reduce the number of problems people have compiling the ALFS system.

  Second, there are some really nasty package management issues that we will
have to deal with if we wish to allow the upgrade of system libraries.
Specifically, will we require users to recompile everything if they upgrade
glibc? I realize that there are ways around this and we will need to choose one.My gut reaction on this issue is that we should provide a package reference
count which must be 0 to allow the deinstallation of the package.

  Third in my list, is the IPC issue. I think that the quick, dirty and simple
solution to this problem is to use XML for the communication. This will allow
protocol extensions and revisions to occur as DTD changes; capitalizing on the
power of XML. Unfortunately, doing so will require us to settle on the DTD for
this communication.

  Last, I'd suggest we don't write off the package management stuff for the
future; a database (of some sort) will have to be interfaced with the backend.
Choosing a way of managing the data will require a large suggestion as well.

I hope that my ideas on all this ALFS stuff provide for some new avenues of
discussion and thought before the project moves forward. No matter what, I hope
that everyone will agree with my assessment that choices will have to be made
about all of these issues to prevent several addition ALFS rewrites.

-John Schmerge (jbs)


-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the alfs-discuss mailing list