Fwd: alfs-email

Gerard Beekmans gerard at linuxfromscratch.org
Thu Aug 31 07:12:49 PDT 2000


----------  Forwarded Message  ----------
Subject: other alfs-email
Date: Wed, 30 Aug 2000 01:23:03 -0400
From: Bryan Dumm <bdumm at bobby.bcpub.com>

Profile/Meta-Language/XML structures

Howdy,

I got several things to point out and this might
need seperated, but I wanted to get this out into the
thoughtstream.....

We have been working on an API that worked like
this

front-end <--> profiler <--> profile <--> lfs-compiler

Now we did this so that we can have multiple front-ends
or lfs-compilers. The idea was that for front-ends we
could have gui's, command prompts, web front-ends etc.
This is also the same for the lfs-compiler but instead
it is different languages like bash, perl, C, C++,
Python, etc.

I have been testing out the xml profile, by building a
sample one, using some perl code(my lfs-compiler) to parse
the profile and some build functions so that I could make
packages or perform commands that setup a LFS.

In doing so I have ran into several problems. I am going
to use the LFS book and Richard's alfs scripts to demostrate
the problems with our current approaches, what needs to be
done to solve these problems, and why an API is the way to
go for automation, and I will include some sample API pieces
along the way.

Okay when you look at the LFS book from a generic profile
context, the first thing you realize is that the LFS book
as it is, is automated through use of the command prompt.
Richard's scripts take it to the next stage which is
the automation of all those commands entered into the
command prompt, with additional automation features(ie logging).

Now that is all fine, and both the LFS book and Richard's
scripts work exceptionally well. :) But that means that,
all of our automation is command line based. This leaves out
other languages from participating because they use their
own features to do command line things, or you do what
Richard did, and use a language to simulate what needs to
go on at the command line.

An example shows this in action. From the LFS2.4 book and
Richard's scripts let's look at the password/group section.

LFS 2.4

Create a new file $LFS/etc/passwd by running the
following command:

root:~# echo "root:x:0:0:root:/root:/bin/bash" > $LFS/etc/passwd

Create a new file $LFS/etc/group by running the
following command:

       root:~# echo "root:x:0:" > $LFS/etc/group
       root:~# echo "bin:x:1:" >> $LFS/etc/group
       root:~# echo "sys:x:2:" >> $LFS/etc/group
       root:~# echo "kmem:x:3:" >> $LFS/etc/group
       root:~# echo "tty:x:4:" >> $LFS/etc/group
       root:~# echo "uucp:x:5:" >> $LFS/etc/group
       root:~# echo "daemon:x:6:" >> $LFS/etc/group
       root:~# echo "floppy:x:7:" >> $LFS/etc/group
       root:~# echo "disk:x:8:" >> $LFS/etc/group

This is Richard's script that simulates the above
with Richard's extra features.


#!/bin/bash -ex
# alfs/passwd_group

# Create /etc/group & /etc/passwd

case $1 in
  pre-test)
    ;;
  install-tarball)
    echo $stage >> $log

    echo "root:x:0:0:root:/root:/bin/bash" > $LFS/etc/passwd

    echo "root:x:0:" > $LFS/etc/group
    echo "bin:x:1:" >> $LFS/etc/group
    echo "sys:x:2:" >> $LFS/etc/group
    echo "kmem:x:3:" >> $LFS/etc/group
    echo "tty:x:4:" >> $LFS/etc/group
    echo "uucp:x:5:" >> $LFS/etc/group
    echo "daemon:x:6:" >> $LFS/etc/group
    echo "floppy:x:7:" >> $LFS/etc/group
    echo "disk:x:8:" >> $LFS/etc/group
    ;;
  *)
    echo $stage: $1: not implemented
    exit 1
esac

Now in a language like perl I would do
the above completely different. I don't
need echo or redirection as I got the
open function and filehandles. And doing the
above in other languages wouldn't be done like
the above unless you were trying to simulate the
command line enviroment.

Thinking about the above in a generic xml format
it might look something like this

<commands>
echo "root:x:0:0:root:/root:/bin/bash" > $LFS/etc/passwd
</commands>
<commands>
echo "root:x:0:" > $LFS/etc/group
</commands>
<commands>
echo "bin:x:1:" >> $LFS/etc/group
</commands>
<commands>
echo "sys:x:2:" >> $LFS/etc/group
</commands>
<commands>
echo "kmem:x:3:" >> $LFS/etc/group
</commands>
<commands>
echo "tty:x:4:" >> $LFS/etc/group
</commands>
<commands>
echo "uucp:x:5:" >> $LFS/etc/group
</commands>
<commands>
echo "daemon:x:6:" >> $LFS/etc/group
</commands>
<commands>
echo "floppy:x:7:" >> $LFS/etc/group
</commands>
<commands>
echo "disk:x:8:" >> $LFS/etc/group
</commands>

Now that doesn't look too appealing, there is
no structure that you can make out of it, and
from a programming perspective is not fun, as
you never know what might appear in the

<commands>
</commands>

tags.If you look at the LFS book, there are
plenty of different commands to cause backend
profiler programmers lots of confusion.

Considering such, take a look at this structure
instead. It doesn't follow the LFS book, but
see how it addresses all of the above problems
correctly.


<config_files>
      <name>
      passwd
          <location>
          /etc
          </location>
          <data>
          root:x:0:0:root:/root:/bin/bash
          </data>
      </name>
</config_files>
<config_files>
      <name>
      group
          <location>
          /etc
          </location>
          <data>
          root:x:0:
          bin:x:1:
          sys:x:2:
          kmem:x:3:
          tty:x:4:
          uucp:x:5:
          daemon:x:6:
          floppy:x:7:
          disk:x:8:
          </data>
     </name>
</config_files>

>From these structures you can see how the

object is formed, the parent-child relationships
of the data, and for programmers it is a more defined
structure that they can use and a clear way to deal
with the data that comes from this structure.

Considering the problem presented above, what
can we do about it? Similiar type problems occur
throughout the LFS book, two other good examples are
the creation of all the base LFS directories and
the use of sed during package installations.

Since we are going to have this problem in a number
of different areas. I suggest that we start creating
xml structures/objects to build a standard LFS. Some
examples of structures we can create are

Package Structure
Patch Structure
Config file(/etc) Structure
Init Scripts Structure
Generic Command Structure
Logging/Enviroment Structures

I think these basic structures should provide us the
ability to build any LFS straight from a master profile.
And the backend can be in bash, perl, C or whatever.

If we can get to the point where we have some standard
structures to build LFS automatically, I don't think it
will be too far of a stretch to add other structures so
that we can build more complicated things, or be able
to featurize the basic structures we have now.

-------------------------------------------------------

A more detailed profile follows shortly after I add a few things to it. That 
other profile should give you a better idea what we currently are thinking 
about.

-- 
Gerard Beekmans
www.linuxfromscratch.org

-*- If Linux doesn't have the solution, you have the wrong problem -*-





More information about the alfs-discuss mailing list