A new aproach
vassilidzuba at nerim.net
Tue Sep 24 11:49:09 PDT 2002
While these are interesting ideas, i'm not sure I agree with all of them...
The books teach how to build a minimal (LFS) or not-so-minimal (BLFS)
Once one has understood how to build the system, the ALFS tools allow
to avoid all the manual command entry while building a (B)LFS system
for a new system, or tweaking some compilation options for instance.
The ALFS profiles are therefore much more likely to be modified by the user
than the book, for instance to add ./configure options, etc. It is hopeless
to want to build the "universal" profile that is likely to satisfy all users.
I think that there should exists many different profiles, and that these profiles
should as far as possible be highly modular.
For instance, for the LFS, one could have :
- a basic profile following the book as closely as possible
- a profile to cross-compile a distribution
- a profile to build a repair/installation CD-ROM distribution
For the BLFS, one could have profiles to build :
- a gnome-based workstation distribution
- a kde-based workstation distribution
- a small server (web+e-mail) distribution
- a firewall distribution
To reach that objective, I think that it is more important to keep
the DTD simple and the profiles modular so that anybody that has manually
build a LFS should be able to tweak a profile, and build its own
On Tue, 24 Sep 2002 17:03:50 +0100
h2k1 <lfs-portugal at netcabo.pt> wrote:
> hello there!
> with this post i do not want to start a new war on this group, but simply
> give a opinion about this project.
> first, i want to say that this is a good project and i would like to
> congratulate everyone that ever contributed to it. the use of xml files in
> a simple program is very different from using scripts. it shows the desire
> from evolution to a more complex, but yet intuitive and powerful as xml,
> system. i think that the main issue here is to build a lfs system from
> scratch, by reading the book and working some aspects on the profiles so
> that the system builds by itself. and not only copy and pasting the book to
> a shell.
> following this idea, i would like to see in the future a new aproach to the
> ALFS program, being ALFS as:
> - ALFS itself;
> continuing doing an automated lfs build.
> - A book reader;
> having the possibility of being possible to read the book while the
> system is being built.
it is already possible now...
For instance you can read the LFS book in a window and run
step by step the build in another window using nALFS.
Of course you need to manually synchronize the two process,
but it's very easy to do.
> - A book editor;
> using the capabilities of vim.
Why do you want to edit the book, unless you are an editor of
the book? If you just want to customize your distribution,
modifying the profile is enough and much simpler.
> - A lfs system files editor;
> same as the book editor, but to write and edit the config files needed
> by the system.
The profile can be written such as it loads the configuration files
from external files so that these files can be edited independently of the
profile XML files. I think that it's almost mandatory for complex files
for which specific applications exists, like the kernel configuration
file and the XFree configuration file,
> - Part of lfs;
> being instaled on the lfs book (this may be an optional program) as the
> official editor/reader of the book.
the beauty of a standard format such as XML is that you don't need an official
editor/reader. Personaly I use emacs to write book fragments,
and mozilla to read them.
> - A blfs editor / installer;
> a blfs ALFS. a graphical frontend (qt/gtk?) for the ALFS.
A ALFS tool is able to build a BLFS system as well as a ALFS one.
Yopu just need the right profile.
While it would be nice to have a qt/gtk front-end for building a LFS
system from a host system, the situation is a little different
for a BLFS system as in this case one might want to build it
from an existing LFS system, that lacks X and all graphical niceties.
A n-curses application like nALFS is well adapted to that situation. Of course,
we both application can exist.
> another important subject is the lfs.dtd . it should be a standard dtd for
> the lfs project,
YEE, YES, YES
> and being used by the lfs/blfs book and ALFS.
i'm not so sure about the book part.
> the project
> needs to create his standards. details as program dependencies and book
> translations could be easily integrated in the project.
yes. BTW, it is not enough to define the syntax of the profile
through the DTD; one needs also to define precisely the semantics,
so that executing a given profile in different ALFS tools
will give the same result. One should be carefull about things
like the scope of the environment variables, the environment
when in chroot, the current user, etc.
> These are the features that i think the future ALFS should contain. i have
> taken in account some of the thoughts brought up here in the last days /
> weeks :) and the hunger for evolution that the current "zeitgeist" on this
> list has revealed. maybe some of them are a bit irrealist, maybe not ;).
> please feel free to comment.
> bye for now
As a quite recent ALFS convert, i think that what the prject needs now is :
- a common DTD (not written in stone yet, of course)
- more people writing profiles and more poeple executing them, to get more
experience with the profile syntax/semantics and its limitation.
The existing ALFS tools are already able to build LFS systems conformant
to the book.
The situation will be more interesting with BLFS, as there are many more
options available to the user in this case. Maybe we will see more interest in
ALFS when the BLFS book will be published and people will start to build more
"operational" configurations from scratch.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss