ALFS/LSB...LSB, your thoughs

Andre Pang andrep at vjolnir.org
Wed Jul 12 01:08:23 PDT 2000


[nb: this message is a reply to both Gerard and Mark Stone]

> controlled via profiles. The ALFS tool can setup a system according to
> LSB specifications by just feeding the LSB profile to the tool and all
> will be done automatically. Perhaps it asks a few simple where

    i'd just like to say that the ALFS profile is a _good_ idea.

> That's the reason why ALFS started. A while ago I realized that LFS is
> fun for a single person but if you have an office with 50 workstations,
> the guy in charge of putting LFS on the systems will roughly do it like
> this:
> 
> On the first system he'll the time of his life
> On the second system it'll be "ok been there, done that"
> By the third time he'll curse the creator of LFS who didn't think about
> automizing stuff and will send a flame or two to the creator (that would
> be me)
> 
> So ALFS was born. Then LSB came around just at the same time and there
> is a great opportunity here.

    you're blurring the line between a distribution and 'just an LFS system'
here -- from the sounds of things, ALFS looks to be like a distribution
based on the concepts around LFS, which are also the concepts around every
single other distribution in existence.  Debian uses dpkg to manage its
packages and to automate the building of source code, and Red Hat uses rpm
to do the same.  note that 'automate the building of source code' was
mentioned there -- it's _very_ easy to build SRPMs and source debs and it
would probably take a whole five-line script (or less) to build an _entire_
system from scratch from source, like LFS, with full dependency checking and
package management thrown in.

    i'm not trying to tell people that ALFS is useless (far from that, i
think it's a good idea), but you really have to decide on what your target
audience is and what you want ALFS to be.  if you're trying to target
somebody in the above scenario, where you have 50 workstations to install,
and you want them to install an ALFS system -- then where do you draw the
line?  do you simply ease them through the installation process?  do you
want distributed (ie: networked) package management like most other
distributions offer, so you can remove and install a package built from
source across all 50 computers?  do you rely on the user to provide profiles
to do this, or do this himself?  do you enforce an LSB setup, recommend
one, or leave it up to the user's profiles to do this?  do you intend to
support people who build their own wacky profiles and suddenly want to do
things, like, say, putting each package in a separate directory?  do you
really want to have _another_ package management system there when .tgz,
.rpm, .deb and .slp already exist?

    unless somebody convinces me with a very strong argument that ALFS is
not a distribution, i'm definitely thinking it is one.  Linux by itself is
just the kernel and the distribution is the operating system, and if ALFS is
going to automate installation and provide an environment for the user to
work in, it's basically an operating system.

> I've been thinking about that too. I'm thinking about a "Linux newbie"
> scenario where the user has never touched Linux. I don't expect him to
> open the LFS book and setup LFS by him or herself. Automatization is
> required. Then I don't expect him or her to upgrade the system manually
> using configure scripts, compilers and the like. Some automated system
> must be in place (what we call in nice term a package management
> system). So I have been aware of it and have been thinking about what to
> use. We can do it the easy way and use an existing one like rpm, dpkg or
> whatever other tools are used on systems.

    what if the user wants to install a "Red Hat" package on his ALFS
system?  are you going to provide compatibility with 'normal' Red Hat RPMs
and provide the normal dependency structure so that he/she can just pick up
any RPM off the net and install it with a reasonable chance of success? 
what about the installer -- is the target audience really the Linux newbie? 
if it is, you are basically competing with companies like Caldera and
Mandrake.

> But I think it's an even better idea to create our own package
> management system. I know this will take time and all that, but it would
> be great, wouldn't it? Perhaps we can start using something that's
> already out there and at a later point we can always start using our own
> home brewn package management system.

    do you intend to keep LFS and ALFS separate, so that ALFS will use its
own package management system, and LFS will still be a guide to building
your own system?  if that's so, perhaps a section on "how to build Red Hat
from scratch using SRPMs" might be an idea.

    before i start putting down my comments about the BSDs, i'd just like to
ask that you please don't treat these questions in the wrong manner.  i _am_
attacking what ALFS is all about, and the questions really do sound
threatening, because they are -- i'm wondering what the long-term goal is
here.  judging from what i've seen of alfs-discuss so far, you intend to
create an installer and a package management system, which sounds exactly
like a distribution.  i'd love to know where ALFS is going so i can help,
but i've also worked on my own small distribution which is very similar in
concept to ALFS, so i can provide help, and i've got alot of experience
dealing with different ways of package management.  not to mention that
other distributions, such as Gentoo (if it ever gets past the "this only
exists as a word on www.gentoo.org" stage) also intend to do basically the
same thing you guys want to do.

    i'm also raising these questions because i want to know what will happen
to LFS -- as I inferred from some of Gerard's responses, it is a guide on
how to build a system from scratch, not a defined way of doing so.  ALFS so
far doesn't sound like merely a 'guide' -- once you introduce things like a
package management system, you have to do things a certain way; if you
don't, then packages will break.  there is no way to avoid this unless you
let the user do some of his own administration, which requires that the user
has knowledge, which means that he's not a newbie, which then seems to
divert away from ALFS' intended audience.  where do we draw the line, and is
do you want ALFS and LFS to have different goals?  (note: i'm not saying
that having different goals is _bad_; that's not necessarily the case.  i'm
questioning whether that issue has been thought about.)

> > 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,
> 
> I don't have FreeBSD but I do have OpenBSD (version 4.2 I think)
> somewhere which I've never installed. Perhaps I should install it and
> see what's going on there. Or is OpenBSD totally different than FreeBSD
> (I'm not familiar with any BSD flavour for that matter)

    FreeBSD's "package management system", IMHO, is an incredible example of
the whole UNIX philosophy, and is very, very good.  i still think it can be
improved on, but i still think it's alot better than RPMs, debs, etc.

    FreeBSD uses a system called "ports".  a 'port' (which is different from
a 'package' -- see quick discussion of OpenBSD below) is basically like a
RPM .spec file; it is a very simple Makefile, usually around 20 lines, with
information on where to find the package, a short description of it, and
with instructions on how to build it and install it.

    a port is usually built from source code, but there are ports available
for things such as StarOffice, so that you can 'build' a working StarOffice
install on FreeBSD if you have the linux-environment port installed already. 
ports has full recursive dependency checking, so that if you want to install
Enlightenment, it will check dependencies for X, Imlib, all the other
graphics libraries, and go and build it.  it also provides a method to
rebuild an entire system from source code, including the kernel, and it does
this properly, firstly building an environment using static binaries to
provide a full recompilation environment, and then recompiling everything in
that environment.  this is very important, if, for example, you are
switching your FreeBSD system from a.out to ELF.

    anyway, if you want me to elaborate more, ask -- my wrist is injured and
typing -> bad :).


-- 
/ #ozone <andrep at vjolnir.org>; (mobile# 0411 882299)
                               trust in love to save
--
Mail archive: http://www.pcrdallas.com/mail-archives/alfs-discuss
IRC access: server: irc.linuxfromscratch.org port: 6667 channel: #LFS
Unsubscribe: email alfs-discuss-request at linuxfromscratch.org 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