lfs at electro-nic.de
Fri Jan 25 08:40:45 PST 2002
> 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
> 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":
url for "get the source"
url for "homepage"
url for LFS/BLFS chapter
"instalation instructions" consists of:
get the source
unpack the source
patch the source
config the source
The 2. Layer consists of the commands:
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,
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