Ok let's start

Gerard Beekmans gerard at linuxfromscratch.org
Thu Jun 22 16:23:11 PDT 2000


Hi,

Let's give this ALFS thing a start. Please keep in mind as you read
below these are by no means final thoughts. I haven't kept this in a
file and have been editing it for weeks and am now finally publishing
it. I'll do an attempt to write down what's in the back of my head (while
I'm eating 2 sesame seed bagels with ham so excuse the crumbs).

Under the name of the "ALF project" we're going to put together an
installation tool that installs a complete LFS system for you according
to the latest book version (2.3.5b at the moment). This program or
script will be put on a cdrom together with all the tarballs. This means
that the cdrom will be outdated soon since software keeps updating so
new cdroms should be made available periodically (say once a month or
someting to that effect).

I know it's probably too much asked to start developing a GUI right from
start (either X and use the VGA16 server so we're sure it'll run on most
systems if not any and have the MONO server available too just in case.
Or we can use Jesse's favorite FrameBuffer. Or let the user select the
server himself).

Before the GUI is developed let's first concentrate on a text based,
perhaps curses based installation tool. I have specific requirements for
this tool. It can't be just one or more scripts that execute all the
commands in a row and tells you when it's done. This tool (I'll call it
a tool from now on until we know what it's going to be. C program, shell
scripts, or combination of both, or some other way) is going to be
highly configurable and flexible, to the extreme.

The tool can install an LFS system all by itself based on default values
or what the user defines without interruption. This will be the "all
values entered, sit back, get some coffee, read a newspaper, walk the
dog and feed the fish. This will take a while" type of installation
method. 

A second method is the interactive method. Before it does anything, it
always will ask the user to accept the command to be executed or to
execute a custom command. So before it does a 'cd $LFS' it asks you
whether you agree or not. Well, a 'cd $LFS' might be *too* flexible but
I think we should allow the user to even override those basic commands.
This gives the user total, and I mean total control over the
installation procedure. In effect you're doing a manual installation but
you don't have to type the commands all yourself. They're already typed
in for you and you only have to press <enter> if you accept the default
(the command the book would tell you to punch in).

A third method is the semi-interactive method. The user can tell the
tool not to interrupt the installation unless a certain command is to be
executed. For example it will only ask the user to confirm the actual
configuration, compilation and installation commands and it will let the 
tool do the  'cd' 'mkdir' 'tar' and such stuff automatically. When it's time 
to execute 'configure', 'make ...' or 'make ... install' user
confirmation is required. This allows the use to change things like 
prefix'es and such.

Perhaps more methods can be implemented if we can think up more needs.

That's basically it. The tool is going to be extremely flexible but it
will let the user decide how flexible it should be have.
Non-interactive, fully interactive or semi-interactive and let the user
decide what kind of commands to be executed automatically and which one
need user approval.

The design of the tool should be modular. If, for example, LFS starts
using a different package or removes a package, it should be easy to add
and delete. The modular part will probably be based on how I've
structured the SGML files (unless a better way is proposed of course).
Currently if I want to add program xyz, I do this:
1) write the "how to install" parts and save as chapter5/xyz.sgml
2) write the description and save as appendixa/xyz.sgml
3) include it in chapter 5 by editing chapter5/chapter5.sgml and add the
line:
	&c5-in-xyz;
4) include it in appendix by editing appendixa/appendixa.sgml and add
the line:
	&aa-xyz;
5) declare the entities c5-in-xyz and aa-xyz in LFS-BOOK.sgml by adding
the lines:
	<!ENTITY c5-in-xyz SYSTEM "chapter5/xyz.sgml">
	<!ENTITY aa-xyz SYSTEM "appendixa/xyz.sgml">

Removing the installation of a package is simple this way:
edit chapter5/chapter5.sgml and remove the line that includes xyz
You can leave chapter5/xyz.sgml there if you're just testing a new
installation order. Do you want to then re-include xyz.sgml simply
uncomment the line (or add it if you deleted the entire line). Want to
move it up a few positions? edit chapter5/chapter5.sgml, find the line
and put it a few lines higher.

This is how I do it for the SGML sources of the LFS-BOOK. The tool can
use a similar approach to make it easier for us to add and remove
sections.

I think this covers most of it.

LSB comes to mind as well. Like I've said before I doubt that this kind
of tool is what is needed for LSB. Perhaps the tool can have a 4th
method which will be the "Install LFS per LSB requirments". This will
probably be a non-interactive installation and installs the LFS system
the way LSB wants it (that is, if LFS is going to be used with LSB). How
ALFS and LSB are going to work together depends on Mark Stone. Quoting
Mark from a little while ago:

<quote>
I'm very curious what you all think of this. As the LSB meetings wrap up
this week, and as Gerard nears the point where he will require gainful   
employment, there are decisions to be made, decisions that will impact
the future of the LSB and LFS. I have an approach I'd prefer, but before I
go advocating a particular approach to anyone, I'd like to have your
feedback.
</quote>

Mark, not to pressure you but if you can shed some light in this as
early as possible we can mold ALFS into what's needed. Perhaps the need
a LFS-LSB project is needed. If so, that can be started and worked on
parrallel to ALFS.

Having said all this we need to start somewhere. Let's first start at
the very basics - the distribution medium. Some people would tackle that
last, I want to tackle it first. 

The medium will without doubt be a (bootable) cdrom. Must we take
systems into consideration which can't boot from cd due to a too old
BIOS? If so we want to have a boot flop available too just in case.

This cdrom will be created according to Eric Ayer's (are you subscribed to
this list Eric?) LFS-Bootdisk-HOWTO. We won't include instructions how
to create the cd, we just use it so we can create it for others. No NFS
will be used, no /usr loopback file you download and mount. Everything
will be on the CD. This cd will contain the needed development
environemtn. This just means all the programs that are linked statically
will be pre-installed on this cdrom and we use that as the base system.
With that base system we can setup the chroot environment by simply
copying the base system to $LFS. No need to compile what already is
compiled. By having the base system static it eliminates the need to
have Glibc installed on the base system which might make things easier.
We're not worrying about disk space here since a cd has enough of it, at
least so I hope. Perhaps we want the base system to be dynamic and have
a stripped glibc installed (only the dynamic libraries that the base
system needs and the static ones that are used during link time. The
remaining files should be deleted to save space).

Having that said I want to say an important thing and please read it
carefully (and remember it too ;). Before we actually start building
something we have to do quite a bit of talking, agreeing on methods and
more of that. I don't want to have 5 different discussions going around
at the same time. That will be too confusing and I just don't want a
chaos here. This project is too serious for that. I don't want to put
this list on moderated mode so that I have to approve every post. If we
all can agree on this that shouldn't be necessary, right?

So for now I only want to discuss the cdrom itself. It won't take weeks
at all (probably a day or two or three). I just want to hear options how
to setup the starting system. Let the starting system be static so we
don't have to actually compile programs static per chapter 5 "preparing
the LFS system". We can copy the files and then enter the chroot
environment and start compiling.

Of course you guys can comment on all I've said above that's no related
to the cdrom but please don't go into too much detail. Please save that
for when we're getting around discussing that. I don't know what the
next subject is after the cd. I'm sure the logical next step presents
itself while we're discussing how the cdrom should work (also think
about having a boot flop that has to mount this cdrom if needed).

I'm not banning non-cdrom conversations right now but I'd like to keep
them to a minimum so we can go in depth about one subject at a time.
That makes it for all of us so much easier to keep track of what's
happening. And I'm beginning to repeat myself. That means it's time for
me to stop writing now. I should delete the last paragraph but I won't.
Perhaps this little bit of "bad humour" doens't make me look like the
dictator like I've acted above.



-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-
--
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