Defining ALFS and it's initial goals.

Henrik Heil henrik_ml at frost-work.de
Sun Jun 17 11:51:10 PDT 2001


Hello,

this is my first post to the list, so i'll try to introduce myself a
little:

- First: please excuse my funny english

- I'm far from beeing as experienced as i think most of you are with
  linux and developing software

- I didn't even finish my first lfs build (please don't stop reading
  here ;)

- I have a bit of experience with XML an related technologies

I was busy reading the discussion of the last days and understood that
among other things the profile syntax and as a consequence of that the
way the alfs-tool works with it is in the process of being redefined.

I would like to propose a way to write the syntax (not yet the syntax
itself) and an idea of how the alfs-tool(s) could work with it (call
it architecture or so..).
As i don't "live" lfs/alfs right now it is likely that i understand
things wrong, question already reached conclusions ... please don't
feel offended at all and correct me in any possible way

First of all:

From: Jesse Tie Ten Quee <highos at highos.com>
Subject: Defining ALFS and it's initial goals. (was Re: Fwd: Re: Moving on)
Date: Sat, 16 Jun 2001 19:47:16 -0600

> Now, long term goals will always be adding all the jazz, that is,
> Package Management Support, multiple fe/be implementations, IPC/RPC, etc
> 
> But perhaps we are starting to big, perhaps we need to refocus on what
> exactly ALFS is at the core, an alfs profile, and write a simple
> all-in-one ALFS implementation (or tool if you will) (like what is ALFS
> CVS module right now) that once given the profile will install a package
> or system.
> 
> If we do that, we have somewhere to start, somewhere to build from,
> instead of adding everything from the start, which i think is just going
> to cause confusion at this point.
.. 
> 
> We can still create a complete solution, but we need something to build
> on, right now id prefer to concentrate on building a framework, da?

I totally agree with that.

I would like to say something about the higher-level things (like
package-management) but only to propose a way i think we could safely
forget about them until the lower level things work.

Imo a good way to think of how alfs could work is as an open set of
tools that work on a defined set of XML-profiles with variing level of
abstraction.

e.g. (the names and number of steps are only for the examples' sake):

"package-manage-profile".xml 
     | 
     | xml-to-xml processor
     | 
"command-profile".xml
     | 
     | xml-to-xml processor
     | 
"shell-profile".xml
     | 
     | xml-to-sh processor
     | 
build lfs

why?

1. Every xml-processor can be written by a different person/group,
   maybe in a different language (see language discussion) as long as
   its input/output conforms to the next/previous profiles' spec
   (DTD/Schema)

2. As i understood lfs is mainly about choice and control.
   Where you want what level of control depends on your knowledge in
   this particular area. (maybe i would like to control the way apache
   is build to the last detail while i only want some kind of working 
   X11).
   A single processor that can cope with these different levels has to
   be very "smart" and it has to be updated every time when something
   on any level of abstraction is changed.
   I propose many "dumb" processors with xml-profiles as an
   interchange format. So i could generate my "command-profile" from a
   "package-manage-profile" with some syntax that says that i want X11
   (with no more details) and then append a very detailed and long
   section on apache with any text-editor in the generated
   "command-profile".
   This way we could start at the low-level profiles with some sort of
   a xml-to-sh processor that has a very defined (and limited)
   featureset. discussions and proposals on higher-level features
   would not interfere with the development of the
   low-level-processors.

3. Imo this would really make maximum use of the strength of xml being
   a format that considerably easy to read/write for humans and
   considerably easy to parse/transform/create by an application or
   script.
   In other words: if you put all the logic in one alfs-tool, you will
   always have to modify this tool to change its behaviour in a way
   the authors didn't expect. Then you could rightfully be asked why
   you didn't choose a more human-read/writable input-format.
   If you write a set of tools that interoperate with each other
   without the idea of someone easily hacking around between the
   processing-steps you probably should have chosen a format easier to
   parse than XML).

4. Some of the discussions i read (i.e. C-backend using systemcalls
   vs. bash - i hope i got the point since i don't know C) have the
   choice of a parallel development with a close XML-profile as an
   entry point ("command-profile", which contains "what" to do in
   detail with no asumption on "how" it is done).


... and now my ideas on the syntax of the lower-level profiles:
 
I think the lowest-level-syntax should be only one step away from the
shell-scripts of the lfs-book, a way to express shellcode in XML.  for
example something like this:

<cmd name="mkdir">
  <arg>man1</arg>
  <arg>man2</arg>
</cmd>

<cmd name="chmod">
  <arg>0750</arg>
  <arg>&LFS;/root</arg>
</cmd>

<cmd name="ln">
  <opt>s</opt>
  <arg>share/man</arg>
  <arg>man</arg>
</cmd>

The pro is that one can write a very "dumb" tool to execute this as
shellcode.
The tool itsself (and the dtd) doesn't have to know anything about
valid shell-commands. There are commands, arguments, opts, maybe
longopts (there is syntax to be defined for pipes, return values and
control-structures) - but the idea is to keep almost all the logic out
of this tool and the dtd.

I know that this sort of profile is not really easy to write and much
longer than the shellcode but this is meant to be the first
development step and a basic profile higher-level tools should
generate in later development phases.

For example what i called "command-profile" could be a profile that
makes no asumption about how the desired action is achieved - it just
describes "what" has to be done.

A syntax could be (just what i could imagine):

<create base="&LFS;">
  <dir name="bin" />
  <dir name="root" perm="0750" />
  <dir name="share">
    <link name="man" type="sym" target="../man" />
  </dir>
  <dir name="etc">
    <file name="passwd">
      <line>root:x:0:</line>
      <line> bin:x:1:</line>
      <line>sys:x:2:</line>
      <line>kmem:x:3:</line>
      <line>tty:x:4:</line>
      <line>uucp:x:5:</line>
      <line>daemon:x:6:</line>
      <line>floppy:x:7:</line>
      <line>disk:x:8:</line>
    </file>
  </dir>
  <dir name="man" />
</create>

These are really just exaples to illustrate what i'm thinking of.

My problem with the current profile-syntax is that it is somewhere in
the middle between these two examples-profile-parts.

- It is more difficult to execute in the shell and has a more complex
  dtd than the "shell-profile"

- It is more difficult to write than a "command-profile" and has large
  parts where it "asumes" that the backend is a shell, so it is
  probably (?) harder to parse by a C-backend for example

- It has structures that i would consider to be even higher level than
  "command-profile"-level (package, configure, install ...)

Sooo - this got much longer than it should...

What do you think about it?



________________________________________

Henrik Heil
-- 
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the alfs-discuss mailing list