Profile design

Eric A. Ayer mwalker at
Sun Oct 1 19:16:10 PDT 2000

I have been designing my own version of the ALFS tool, and am running into a
problem.  I really need to figure out how to do the profiles.  Following is
a rather long description of the problem and its solution, although what
exactly the problem is might not be clear.

The way my tool will work is as follows: the program will be called, like from
a command line but possibly from a front-end.  The arguements passed to it
will be parsed, and the things they include will be (required) the name of a
profile to execute, (optional) an environment of shell variables, files that
contain definitions for environment variables, actual declarations of var-
iables, and a few other things.

After parsing the command line, the program will read the specified profile
and turn it into something very much like a shell script.  The commands in the
shell script will be shell "built-ins", single commands, or multiple commands
chained together with pipes.  One big addition to command lines is that they
can contain a "response script."  That will cause the command line to be
executed interactively by another function that scans for expect strings and
responds with response strings.  Text is read from a pipe connected to stdout
of the last command, and the response is sent to a pipe connected to stdin of
the first command.

So a profile for installing a package will have a start tag (XML requires only
one top-level tag so it'll be there, even though it seems superfluous),
followed by one or more tags, such as <configure>, <make>, <make_install>.
Those in turn may have other sub tags.

I've been struggling with the idea of how, exactly, to specify data for the
commands.  As an example, consider the <configure> tag.  It will possibly
require some data, like the parameters attached to the command, and it will
have some data that is optional, and has defaults.  The prefix to the command
may default to "./" (without the quotes), but allow that to be changed to
something like "../glibc-2.1.3/".  Likewise, the command itself might default
to "configure", but Perl would require it to be "Configure", so the default
could be overridden.  There are multiple ways to do this: first, the variables
both required and optional could be part of the start tag.  One could use

<configure args="--prefix=/usr" prefix="../glibc-2.1.3/">

Alternately, at least some of it could be specified following the start tag as


Personally I don't like this.  The required part (arguements to the command),
and the optional part of var="data", don't mix too well.

The last mothod is to include stuff as sub-tags:

	<args> --prefix=/usr </args>
	<prefix> ../glibc-2.1.3/ </prefix>

An additional problem exists with this: Everything under the top-level tag
does not return data.  The top level tag would just contain the configure,
make, install tags, which would generate code for the "shell" script that
eventually gets executed.  Under configure, however, the sub tags have to
return data.  This will probably be in the form of local "variables" that will
be used in creating the command lines to be executed (these variables are
different than environment variables - they are local to the translation of
the XML script translation).  How does one specify where to put the returned

My solution is to limit the specification of variables in the start tag to
mappings of local variables in the child tag to variables in the parent tag.
In the configure example above, a local variable to the parent, say args_conf,
might be mapped to the character data contained within the child tag, <args>.
Then, all dissimilar data would be specified in sub-tags, not as #PCDATA
(In a document type definition, or DTD, a tag is specified as having #PCDATA
which is text, and/or other tags being contained within a tag).  In the
example above, a child <args> tag would be required, and <prefix> and <command>
tags would be optional.  In a <move_files> tag, there would be tags required
for source and destination directories, and data for files to be moved.

This mapping of variables would have to be done in the definition of tags,
like in the DTD.  It would be confusing to have it done when the tags are
actually used to specify data for a program, like configure.

These are problems that will determine what profiles look like when they are
used.  It also determines what they will look like when they are specified.  I
believe that I have one way of doing it that would work and be easy to code,
but would like feedback on my ideas.


Unsubscribe: send email to alfs-profile-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list