automated profile generation
bookreader at gmx.com
Fri Mar 19 20:26:59 PST 2004
On Saturday 20 March 2004 02:44, Kevin P. Fleming wrote:
> Reinhard wrote:
> > I would like to offer the profiles for testing and discussion.
> > Don't know, whether it's ok to send to the list.
> > It's an tar.bz2 with 64k.
> > bz2 was not mentioned in the spam-update from Gerard, but may be better
> > ask before sending :)
> No, I wouldn't recommend sending to the list. If you've got webspace
> somewhere you can post it there and send a link, or if one of the LFS
> team members gets involved they can put it in their webspace on the LFS
Yes, I thought about that. Currently I don't have webspace, therefor I only
can send it via mail.
> > 23 out of 341 failed cause of tricky usage of sed command.
> > May be an ALFS-insider could give me a bit assistance on how to do
> > command chaining or how to convert a sed command, where source and target
> > differ ...
> IMHO you're going to have trouble completing and/or maintaining this
> method of profile production. If it were me I'd take a long look at
> lfscmd and see how it extracts the commands from the XML ...
Hui Zhou send me the link of homepage of lfscmd.
I had a quick look at it - and found 2 major reason not feeling well on that
1. the headline "simplicity"
My motivation is NOT simplicity, but reliability - also the result may be
2. lfscmd needs another knowledge-base beside the book.
I am totally against any knowledge-base which has to be edited beside the
book, as long as its avoidable - means:
I would prefer spending my time on editing the book than investigating another
language and creating whatever profiles or graphs. If you change the book for
not having to edit any profile - its a very good intention and I would like
to support that.
> ... and then build something that works that way.
That's no problem at all. I also did it that way and the command extraction is
quite trivial compared to the need of translating the commands to fit into
My script works for me.
I build a server with 115 packages from blfs and I only had to fix some
dependencies (in the book). Finally the build-script of only one package
needed to be edited cause of unusual naming of the tarball (and I think that
even such a thing could be solved by a script or processor).
With my scipt I found lots of typos and uncommon naming of the tarballs - and
for most of them I found a way to deal with it.
So finally I have a method wich is able to install packages and only uses the
book. Well, of cause there are to additional files:
one to hold the packages, you like to install (your wishlist)
one to hold the packages, that are installed.
Both can be edited, whenever you change your mind ...
So I did not join this list cause I needed help in build process.
My script works fine for me and suits my needs.
I joined cause I have a working system and I thought, may be I could give
a little bit back to the community...
> Also, the LFS book (and probably the BLFS book) are about to experience
> a complete change in the way their XML is structured, so your script will
> probably break badly very soon :-(
*LOL* I don't consider that a problem but a challenge. My script is build
modular, so little changes will be necessary.
By the way: if there is any interest on editor-assistance - I'm willing to
The book-scanner is not the biggest module and not the most complicated.
IMHO the translating of the commands in nALFS-profile syntax is quite a bigger
job. Even more, as I don't have a knowledge of the ALFS-internals or future
plans about profile syntax.
The problems I mentioned may result in a change/expansion of the nALFS-DTD.
But I can't estimate that - so I asked for discussion on that points.
More information about the alfs-discuss