Some thoughts

Jay Bennie jay at lincore.com
Fri Jan 25 10:55:06 PST 2002


I have a Q.

Why is it important to merge the XML profiles of ALFS with the LFS book
profiles, Surely they are different things and merging them only serves to
add an unnessisary degree of complexity to what is in essence a really
simple thing to do.

If the argument is to ensure that the instructional code of the install
profile can be copied to the book, why not run a script to extract the
relivent bits from 1 profile into the other. isnt that the reason why XSLT
was developed.

Rule 1 in my development book is KISS (Keep it simple stupid)
Rule 2 don't add new requirements untill the existing ones are implemented.
Rule 3 : try where possible to keep track of implemented requirements.

-------------------------
heres an idea, for every package XML profile theire is an assosiated
help/doc XML profile. this way they are seperate and the parser can choose
to ignore the help. (the Help/Doc is extracted from the LFS book profile
using XSLT)

This would fit in nicely with the hierarchical Parent /child(brother/sister)
method that i described back in november.



----- Original Message -----
From: Nicolas Nieswandt
To: alfs-discuss at linuxfromscratch.org
Sent: Friday, January 25, 2002 4:40 PM
Subject: Some thoughts


>    o We are using XML as syntax and means to describe our profiles.

First of all, I like this Idea very much. The future speaks XML ;)
But would be better to implement XML than using some XML.
For portability reasons it would be better to use XInclude than a selfmade
include.

>    o We want to keep the syntax as simple as possible.
>
> Think "user friendly" if you will.  Simple to read, simple to
>     write, simple to use. [yes i know that's easier said then done]

My dream is an aLFS that show the LFS-book-xml and highlights the current
step. But I think that's to much work for bit of comfort ;)

Could we use XSLT to transform the LFS book to a profile ? All informations
are in there and they are simple and user friendly. The structure of the
should be the structure of the profile.

Since the LFS-book is in XML, what about merging the profiles into the
LFS-book ? Then you have only one thing to maintain, but I don't know how
realy XML safe the DOCBOOK-xml format is.

Creating the Book would be one XSLT, creating the profiles another. Same
procedure for the hints. Thats an idea of xml: hyperlink the resources (LFS,
BLFS, Hints, sources, ..), isn't it?

The book has all info's to fill the meta tags.
The meta data could be created by fetching the [fm] xml project record.

Already posted here, it would defenately be useful to have "if/then/else" to
write one profile for static and dynamic build.

The textdump tag should only have a basic function, because automated
editing of configuration files used by more than one package makes no sense.
Wether patch nor sed could handel this. The user should make such
configuration by Hand. Giving him a suggestion what and where he have to
add/remove/change some lines and the possibility to do this with an editor
out of the frontend.

>    o Portability is an issue we want to consider and take into account.
>
> That's one reason we don't consider shell scripts the right
> solution.  So, when writting profiles, you have to take into
> account and consider that not all implementations are using
> the standard command line tools. (like most ALFS presently are)

Portability should be no problem since the syntax is simple ;)
The instrucions have 2 Layers, the 1. Layer consists of:

"meta data / info's":
name
version
description
url for "get the source"
url for "homepage"
url for LFS/BLFS chapter
dependencies

"instalation instructions" consists of:
prebuild
get the source
unpack the source
patch the source
config the source
build
postbuild
install/mkdirs
config/create scripts
clean/delete

The 2. Layer consists of the commands:
move
copy
find_replace

unpack
configure
compile/make

system_command
create_config_file

The 1. Layer discribes static data to show infos to the user and get the
download. No problem for portability

The 2. Layer is a wrapper for the system dependant commands. The tags should
describe what these commands are doing. Changing the system should then
result in using the compatible commands on these systems.

>     o Issues that I consider we should hold off.
>
> Package Management, "Smart Profiles" or adding extra meta data
> are things i'd like to ignore untill we have an initial release
> finished.  And just concentrate on making a simple, working,
> build system.  However, feel free to discuess these topics if
> you want, just remenber that the goal of this thread is for us
> to agree on a common syntax.

What about creating a XML Database for Packet Management ?

Just my confusing ideas for 2 euro-cents,

nico

--
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