the move to custom xml

Jesse Tie-Ten-Quee highos at linuxfromscratch.org
Tue Apr 8 15:18:07 PDT 2003


Yo,

On Tue, Apr 08, 2003 at 05:56:01PM -0400, Seth W. Klein wrote:
> Not really, i'm afraid. The issue for me is automation. To put it
> bluntly, i wish (need, perhaps) to do things with my life besides
> building LFS. Gerard's goals for the LFS project have explicitly
> excluded automation and so i would be foolish to expend more than
> a little effort on the LFS Book itself.

Ohhhh, Ahhh... *hugs Seth*

> 1: It invents a new (XML) format for commands when we already have
>    (ba)sh. This is not ideal because, not only does it save effort
>    to use an existing tool where possible, but reinventing sh is
>    unlikely to produce anything better since if there was anything
>    better someone would have developed it in the last 30 years or so
>    during which far brighter minds than ours have been using Unix sh.

Well..  The XML for ALFS never *suppose* to replace the shell.  The
current incarnations do somewhat that, and I do agree it's wrong.  But
that has more todo with *how* you decide to implement it.  If you kept the
original goals of just writting a specification of the XML on the
information stored, then you could do anything with that information.

If that means converting it via an implementation like nALFS does into
basic shell commands that are run todo the job, or to convert it to
actually bash shell scripts, wouldn't matter.  As that's not what ALFS was
suppose to be about...

But that's a different topic for a different list :P

> 2: It encourages ALFS processors to be large monolithic applications.
>    The 35 years and counting of Unix use suggest that the typical
>    Unix design involving small specialist tools written in whatever
>    language is most suited and communicating via pipes and files is
>    the wisest design to use unless it proves absolutely unsuited to
>    a particular application.

*smirks*  Ya, like current mainstream implementations of sh are anything
but bloated.  (hello tcp/ip features)  (besides, what I wrote above still
hods true, imho)

> My next step is storing and extracting build commands. I will be able
> to to do something like:

> $ make stage1.sh
> xsltproc --xinclude --withstringparam want stage1 build.xsl index.xml
> $ su - -c "sh `pwd`/stage1.sh"

Uh, i'm slightly confused after reading all that.. did you convert
everything into scripts in one shot, or are you actually putting all the
information into XML and then using XSL to convert it to a shell script?

It does sound interesting and you raise alot of points I would not mind
discussing further ;)

> My one concern is the check script which hits ftp.gnu.org once for
> each package from there. I could see them getting quite argry with me
> if 500 lfs-dev subscribers got home between 17:00 EDT and 18:00 PDT
> and ran the thing. It would be even worse if a few thousand freshmeat
> or slashdot readers got wind of it.

Could use the http interface.  Less work for the FTP server then, you'd
think.

-- 
Jesse Tie-Ten-Quee  ( highos at linuxfromscratch dot org )
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list