My newbie detailed analysis of the profile

Simon Perreault nomis80 at
Wed Sep 6 16:58:35 PDT 2000

First of all, let me say that I think this profile thing is the most important
step of the way. Much of the success of ALFS depends on how good the initial
concept of the XML standard will be. So I think we need to do a LOT of thinking
before even touching the keyboard.


We can talk about two kinds of variables: local ones, and environment ones.

Local variables are variables which will be used in the profile itself. For
example, all the variables contained in the <defaults> tag near the beginning
are considered as local variables. Those variables are going to be used
differently by every backend.

Environment variables are variables that are going to be send to the shell to
become real environment variables. For example, when you use the "CC=/usr/..."
environment variables before compiling glibc, you are using an environment
variable. Environment variables need to be sent to a shell before a
command using them is performed. And I'm saying A shell, not THE shell, because
you're not always using a shell. Often, I'm working in Xwindows without any
shell running anywhere. So if I fire up ALFS not from a shell, it will have to
create its own. Will it always reuse the same shell, or spawn a new one for
each command that needs one? This has to be discussed (I have no opinion). In
the latter case, the environment variables need a way to specify which
following tags will need these env vars set.

It is evident that we're not going to use <variable>value</variable> to define
variables. We need a way to differenciate from local and env ones. I am
proposing this:

<local name="">value</local>
this is for local variables

<env_var name="">value</env_var>
this is for env. vars.

I didn't see a need to use similar names for the tags, as their use will not be
even close to similar. In fact, naming them completely differently will force
people to think about the differences between them.

Also, why didn't I use <local name="" value="">, or <local value="">name</local>
instead? Because a tag is applied to what is inside it. This is simply more
logical, and more intuitive.

Also, we could do something like this:

<local name="" [description=""]>value</local>

This way, the front-end could present the descriptions of the variables, and
the user could change the default value. Variables without a description
attribute would be considered as being non-optional.


Why? I've always wondered what was the purpose of <html> in HTML. Could someone
enlighten me on the use of the <alfs> tag?


Why so? Why do we need a <defaults> tag? What's the use? Shouldn't we use
<!-- defaults -->
instead? I saw many tags in the profile that could/should be replaced by
comments. When a tag has no use, it doesn't need to exist. And I see no use to
the <defaults> tag. Please enlighten me.


An optional type="" could be added. Remember: we're writing a standard. Some
things in that standard don't need to be used in the LFS profile itself.


Couldn't that simply be replaced by a <mkdir dirs=$mountpoint> ? We have to
keep the number of tags to a strict minimum. If a tag doesn't do anything
differently than another tag, then it has no reason to exist.


May I humbly suggest that it be changed to <mount> instead? This would be
simpler, and easier to type.


What's the use? Why do we need to enclose a bunch of <mkdir>'s and <cd>'s in a
special tag? I suggest we use <!-- creating dirs --> instead.


Maybe I'm being a little stupid, but I'm wondering how variables will be
delimited (is that an English word?). For example: <cd dir=$lfs>. How does the
backend know that $lfs is a variable? By the `$` ? If so, then how does it know
that $lfs/usr is "variable lfs" + /usr ? I know these are stupid questions, but
I put them here just to stir some thinking.


Instead of using <mkdir dirs="">, I'd rather use


since we must remember that what's contained between the tags is the "target"
of the tag, it's subject. The tag's effect is applied to it's content.

I think the <cd> tag should behave the same way.


I think the <link> tag is very good. But I'd invert the source and dest. Let me
explain my logic:
A link is a sort of tunnel that takes you from somewhere to somewhere. So,
first of all, I'd change "source" to "from", and "dest" to "to". They are only
esthetic changes, and not very important. But I think they're more significant
this way. Second, I'd state that the from="" is going to point at the link, and
the to="" is going to point at the actual file, since when you use a link
you're going from the link to the real file. Anyway, these are only cosmetics,
and any way would please me.


Again, I'd like to see the target of the tag being in between a starting and an
ending tag, like this:

<change_mode value="">root</change_mode>


One simple question (I'm too stupid/newbie to figure it out): what's the use?
Will the profiler/backend/front-end use them in any way? Are they here for
cosmetics? If so, then I suggest they be replaced by comments. We shouldn't
force people to write well-organized profiles.

I see some use for the <package> tag: the <name>, <version>, and other
package-specific tags need to know to which package they belong. In this case,
wouldn't it be simpler to use:

<package name="" version="" topleveldir="" etc etc etc>
package building, installation, and other stuff


What's the use? What do we need to know the version for? Will the
backend/front-end/profiler/whatever use this information? The only way I can
see that it would be useful is for upgrading purposes, and then again it's
still very blurry. Remember: tags that do nothing have to be eliminated.
Comments can be used instead, if the info they provide will only be seen by
browsing the profile itself.


The <command> tag will be used to send lines to a shell prompt. So, using tags


is irrelevent since the only thing the backend is going to do is put the make
and install together and send it to the command line. Let's keep it simple, and
do that job for the backend in the profile itself. When something needs to be
sent to the command line, let's simply use

<command>make install other stiff prefix=$thing something --with-joy

If I'm off track, or simply dumb, say so, and tell me why.


I also suggest that source and dest be changed to from and to, simply for
cosmetical purposes. Please hit me on the head if I'm being stupid.


Will this be used differently than simply including it in the <command> tag? If
so, how? I suggest, as I said above, that it be included in the <command> tag.


I think the way files are edited is quite good. But what if I want to search
for multiple strings, and replace them with multiple strings? How is the
profiler going to know what <replace> tag goes with which <search> tag? Are we
restricted to use them one by one, in chronological order? I suggest we use
some sort of id="" to know what tag goes with what tag. Then, we can use
constructions like:

<search id=patate>patate</search>
<search id=patate>poil</search>
<replace id=patate>pomme</search>

In this example, all instances of "patate" and "poil" will be replaced by
"pomme" (I should always use french words for stupid examples! Yes, good idea!).


In the <version> tag of the Diffutils package, there is a fairly evident typo.


Our profiles need to have some way to do at least basic conditionals. One
example: do I need to install GCC on the normal system? How are conditionals
going to be used? Enclose them all in structures like this ? :

<if condition="What is going to be the syntax for a condition? There are
different types of conditions, and they are going to be evaluated differently.
How are we going to deal with that?">
	do stuff
<ifnot condition="">
	do suff that you wouldn't do in the if condition above (sorta like an

Are conditionals relevant to an ALFS profile? Am I bloating this too much? How
are conditionals going to be dealt with?


I simply don't like these. What are they used for? They're simply used to
declare local variables. So I say they should make use of the <local> tag


Take a look at a ./configure script.


Why would the command need to be changed?


Are they simple <command>make target</command> tags, or do they differ in any


What if there are multiple patches to be applied? I think we should use <local>

And, while I'm at it, why not invent another variable tag that is going to be
used to define variables that are only present in a given package. For example,
I don't want to redefine topleveldir everytime I build another package. This
variable should be defined only in it's parent <package> tag. So maybe we
should use another tag to define that kind of variables.

ABOUT THE condition=present THING

Needless to say, we're going to need some sort of conditional to do this kind
of thing. Look above for my opinion about conditionals.


In what way is it different that a <command>./configure niaiserie</command>
tag? We have to limit the number of redundant tags.


We don't need <config_file> tags. We only need <edit> tags, like you used
before to search and replace text in a Makefile. We could do config files like

<edit file=caca>
texte stupide en français parce que c cool de mettre des exemples en français
pis que personne comprend sauf des élus qui s'envoleront avec les
extra-terrestres de raël pour aller vivre des méditations sensuelles avec les


Again, what are their use? We have to use comments if a tag has no purpose.

------------------------------cut here-----------------------------------------

Ok, this email has taken me long enough to write. I hope it will be useful into
writing the standard. When it's written, I'll suddenly become very silent
(unless you give me some doc to write). I really gotta learn something better
than bash or HTML.

As usual, this is only my newbie advice.

-- Support your government, give Echelon / Carnivore something to parse --
classfield  top-secret government  restricted data information project CIA
KGB GRU DISA  DoD  defense  systems  military  systems spy steal terrorist
Allah Natasha  Gregori destroy destruct attack  democracy will send Russia
bank system compromise international  own  rule the world ATSC RTEM warmod
ATMD force power enforce  sensitive  directorate  TSP NSTD ORD DD2-N AMTAS
STRAP warrior-T presidental  elections  policital foreign embassy takeover

More information about the alfs-discuss mailing list