My newbie detailed analysis of the profile

Thomas 'Balu' Walter tw at itreff.de
Thu Sep 7 08:19:34 PDT 2000


+-Simon Perreault-(nomis80 at hotpop.com)-[07.09.00 03:33]:
> 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.

Big ACK!
> 
> ABOUT THE VARIABLES:
> 
> We can talk about two kinds of variables: local ones, and environment ones.

Add global ones - for all "included" (however that is done) profiles
and local ones for every smaller <package>

[description of local and env-vars]
> <local name="">value</local>
> this is for local variables
> 
> <env_var name="">value</env_var>
> this is for env. vars.

idea:
<variable name="name" type="global">value</variable>

and similar.

> 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.

local values might be used as environmental-vars...
> Also, we could do something like this:
> 
> <local name="" [description=""]>value</local>

great idea.

> 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.

non-optional if the description is missing? I don't understand what you
want to do here.
> 
> 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?

It describes that the following document is an ALFS-one. Perhaps we
should even do an:

<alfs version="0.1b"> So that the profilers can differ between them "Hey
I don't know how to handle that profile - it's too new" ...

> 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.

It is meant to structure the profile - the profiler knows that the
defaults start here and end there.

> 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.

This is to give the compiler a chance to choose between using commands,
or functions that each language has - e.g. <delete_file> could be done
with "rm -rf" or unlink() in c... 

This is also the description for many other "not-needed"-tags
> 
> THE <MOUNT_FILE_SYS> TAG
> 
> May I humbly suggest that it be changed to <mount> instead? This would be
> simpler, and easier to type.
> 
> 
> 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.

I was not sure about that either.

> 
> ABOUT THE <MKDIR> AND <CD> TAGS
> 
> Instead of using <mkdir dirs="">, I'd rather use
> 
> <mkdir>dirs</mkdir>
> 
> 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.

agreed
> 
> 
> 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.

man ln :)
> 
> 
> 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:
> 
> <change_mode value="">root</change_mode>
> 
> 
> 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.

The profiler has to know where each section starts - you would not have
to use <title> in html though.
> 
> 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
> </package>
> 
> 
> 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 version is not only needed for upgrading purposes but also for
checking dependencies and such.
> 
> 
> THE <COMMAND> TAG
> 
> The <command> tag will be used to send lines to a shell prompt. So, using tags
> like
> 
> <command>make</command>
> <target>install</target>
> 
> 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
> --with-sadness=no</command>
> 
> If I'm off track, or simply dumb, say so, and tell me why.

I agree with you here... not dumb. but we should not use that for
commands like mkdir, cd, rm,...

> 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 stuff
> </if>
> <ifnot condition="">
> 	do suff that you wouldn't do in the if condition above (sorta like an
> else)
> </ifnot>
> 
> Are conditionals relevant to an ALFS profile? Am I bloating this too much? How
> are conditionals going to be dealt with?

I was wondering about that also.

> 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
> instead.

Not only - as stated above you might want to use other than
shell-commands to create dirs and such. - But I agree those are
variables... - needed ones.

> HOW TO OBTAIN THE $HOST VALUE
> 
> Take a look at a ./configure script.

is there a tag that describes the architecture that package is meant to
run on?

> THE <PATCHFILE> TAG
> 
> What if there are multiple patches to be applied? I think we should use <local>
> tags.
> 
> 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.

local ones (in spite of the globals)
> 
> 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.

ack - as configure could not be done using a function of a language I
agree.

> ------------------------------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.

Nice thoughts and ideas

> As usual, this is only my newbie advice.

newbies are the best source of ideas for a new product.

     Balu





More information about the alfs-discuss mailing list