My newbie detailed analysis of the profile
nomis80 at hotpop.com
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.
ABOUT THE VARIABLES:
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
this is for local variables
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.
THE <ALFS> TAG
Why? I've always wondered what was the purpose of <html> in HTML. Could someone
enlighten me on the use of the <alfs> tag?
THE <DEFAULTS> 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.
THE <MAKE_FILE_SYS> TAG
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.
THE <CREATE_MOUNT_POINT> TAG
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.
THE <MOUNT_FILE_SYS> TAG
May I humbly suggest that it be changed to <mount> instead? This would be
simpler, and easier to type.
THE <CREATING_DIRS> TAG
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.
ABOUT LOCAL VARIABLES
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.
ABOUT THE <MKDIR> AND <CD> TAGS
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.
THE <LINK> TAG
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.
THE <CHANGE_MODE> TAG
Again, I'd like to see the target of the tag being in between a starting and an
ending tag, like this:
ABOUT THE <PACKAGE>, <PREBUILD>, <BUILD>, <INSTALL> AND <POSTINSTALL> TAGS
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
THE <VERSION> TAG
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
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.
THE <MV> TAG
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.
THE <FLAGS> COMMAND
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.
ABOUT FILE EDITING
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
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.
THE DREADED CONDITIONALS
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 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?
THE <TOPLEVELDIR> AND <BUILDDIR> TAGS
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
HOW TO OBTAIN THE $HOST VALUE
Take a look at a ./configure script.
Why would the command need to be changed?
THE <MAKE> TAGS
Are they simple <command>make target</command> tags, or do they differ in any
THE <PATCHFILE> TAG
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.
THE <CONFIGURE> TAG
In what way is it different that a <command>./configure niaiserie</command>
tag? We have to limit the number of redundant tags.
THE CONFIGURATION FILES
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
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
THE <PRECHROOT> AND <ENTER_CHROOT> TAGS
Again, what are their use? We have to use comments if a tag has no purpose.
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