A new aproach

Vassili Dzuba vassilidzuba at nerim.net
Tue Sep 24 11:49:20 PDT 2002


Hi,

On Tue, 24 Sep 2002 17:03:08 +0000 (UTC)
ewt at avajadi.org (Eddie Olsson) wrote:

> Hi
> 
> I think this is a brilliant approach, and I have a few variations on your ideas that may make this both achievable and even more useful:
> * First a disagreement with your idea, albeit a small one: I think the main distribution form for the book should continue to be docbook and it's derivatives (html and so on generated from the docbook sgml). 

I agree; docbook seems to be the standard for Linux documentation format
(at least in the Linux Documentation Project), is well adapted
to technical documentation and there exists already viewers/printers for the DTD.
Writing a stylesheet (DSSSL or XSLT) for a large DTD is a big work...

> * That said, i think the  'native format' of the book (the format editors work with) , however, should be xml using an extended version of the alfs DTD. The extensions should be done so that both docbook and alfs profiles can be generated from that xml or, better still, used directly by alfs applications. 

I'm not so sure about using directly the book as an alfs profile.
The book exists to allow a reader to learn while building a Linux distro.
ALFS exist so that the reader does not need to do the same manipulations several times.
However, the ALFS profiles are simple enough so that the user could modify them easily
(to modify a configure option, for instance). Embedding the ALFS profile in the book
would make this more complicated.

Moreover, the structure of an ALFS profile could be different from the structure
of the book. e.g. the BLFS book is organized by grouping logically related packages,
while a profile could present them sequentially in the building order (for instance the
BLFS presenst emacs in chapter 6, with other editors, but you will probably wish to
build X, from chapter 26 before building emacs).

Also, there could exists several profiles for a given set of packages. For instance,
one could have a profile to build a normal LFS distribution, and one to build a boot CD,
or to build a cross-compile one, etc.

> *  The DTD should allow for 'alternatives' that can be viewed in the book and chosen in the alfs applications. This is to allow the users to choose between different paths through the installation ie do I use pam or not?, Do I use sendmail or postfix for the MTA? The latter one probably belonging in blfs, but the DTD should allow for a limited set of differentiations of the installed system like this. I realise this can turn in to a bit of a nightmare for editors, but the gains in terms of usefulness are big enough, imo, to at least remove technical obstacles for this. 

I fully agree with the usefulness of adding this functionality to the ALFS DTD (but
one needs to know where to stop before transforming the DTD into a programming language),
I think however that it is not necessary that it be a nightmare for editors, because
they probably shouldn't use it.

One could have in the DTD :

<!ELEMENT if   (test, stage)>
<!ELEMENT test (#PCDATA)>

at execution time, if the content of <test> is "true", the stage is executed.
Of course, this content can contain a entity reference :

<if><test>&pam;</test>
<stage name ="PAM">
...
</stage>
</if>





> 
> The benefits of this new approach, if indeed it is new, are quite obvious. It's equally obvious that there are some pitfalls with it, mainly that it could be hard for editors to readopt to a different model for writing, so I would very much like to get some input from them on this.
> 
> With the book available in xml format where the actual build actions are machine readable as well as human readable (through the application) you could easily read the book while do the installation step by step, making choices between alternatives where applicable or simply build it all in one go with the defaults all the way. It would also give editors a benefit in that they can more easily test a new version of the book by using it's automated capabilities to do a test build on a clean box for QA or whatever, something that I can well imagine being a bit of a pain with the current process.
> 
> /Eddie 
> 
> h2k1 <lfs-portugal at netcabo.pt> uttered the following on Tue, 24 Sep 2002 17:03:50 +0100:
> 
> > 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.
> > 
> > - A book editor;
> >         using the capabilities of vim.
> > 
> > - A lfs system files editor;
> >         same as the book editor, but to write and edit the config files needed
> >         by the system.
> > 
> > - Part of lfs;
> >         being instaled on the lfs book (this may be an optional program) as the
> >         official editor/reader of the book.
> > 
> > - A blfs editor / installer;
> >         a blfs ALFS. a graphical frontend (qt/gtk?) for the ALFS. 
> > 
> > another important subject is the lfs.dtd . it should be a standard dtd for 
> > the lfs project, and being used by the lfs/blfs book and ALFS. the project 
> > needs to create his standards. details as program dependencies and book 
> > translations could be easily integrated in the project. 
> > 
> > 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
> > hugo
> > -- 
> > Unsubscribe: send email to listar at linuxfromscratch.org
> > and put 'unsubscribe alfs-discuss' in the subject header of the message
> 
> 
> -- 
> Eddie Olsson <eddie at kinnekulle.com>
> =========================================================================
> Fingerprint: 2778 87FA 6708 58C0 8261 DFEB C8FA 4591 6E36 FCCB 
> Key ID: 6E36FCCB
> `Those who desire  to give up  freedom in order to gain security will not 
> have, nor do they deserve, either one.' - Thomas Jefferson
> -- 
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe alfs-discuss' in the subject header of the message
> 
-- 
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 mailing list