cvs commit: ALFS syntax.txt

Jesse Tie-Ten-Quee highos at linuxfromscratch.org
Wed Mar 27 09:50:35 PST 2002


Yo,

I know, i know.. this has been discussed over and over again on this
list.  However, i'm trying to now document what we want to use for the
"new" syntax.  So bear with me.  If i don't get any feedback and
suggestions, i'll be going with what i believe is best, so i suggest you
reply :D :)

btw, please ignore all the differences between <base /> and <dir /> for
now.  I'll deal with that at the end of this e-mail.

I'm going to list example XML bits.  First what i've been playing with.
Second what i see in the latest nALFS release (in the LFS profiles).
Then i'll add a few comments after.


>   unpack

<unpack>
    <src />
    <dest />
</unpack>

<unpack>
    <archive />
    <destination />
</unpack>

Here, it's more about what makes more sense i guess and comes down to
personal preference.  Id feel better if someone suggested two better
names for these tags.  I'm more or less torn on this issue.  However i
guess the use of <source /> and <destination /> would make alot of
sense. (even if it is longer to type out ;)


>   configure

<configure>
    <dir />
    <command />
    <option />
</configure>

<configure>
    <base />
    <command />
    <param />
</configure>

The only difference here, is I started to use the <option /> tag instead
of <param /> which i got from the idea of <options /> which is being
used in nALFS for <copy /> and so forth.  I think it's little nicer
then <param /> and makes a little more sense, imho.


>   make

<mkdir>
    <dir />
    <option></option>
</mkdir>

<mkdir>
    <base />
    <dir />
    <param />
</mkdir>

Same as above.


>   execute

<execute>
    <dir />
    <command />
    <option />
</execute>

<execute>
    <base />
    <command />
    <param />
</execute>

Same as above.


>   remove

<remove />

<remove />

No subtags or elements are needed.  I think we can all agree on this ;)


>   copy

<copy>
    <src />
    <dest />
</copy>

<copy>
    <base />
    <source />
    <destination />
    <options />
</copy>

Similar to unpack.  However if we use <option /> with configure and make
(and other tags), the usage of <options /> may seem confusing.  It may
perhaps make more sense to just use <option /> also, while allowing
multiple tags. (so if you need say resursive and resursive, you have
two options, one for each)

>   move

<move>
    <src />
    <dest />
</move>

<move>
    <base />
    <source />
    <destination />
    <options />  (i believe?)
</move>

Same as above.


>   link

<link>
    <dir />
    <src />
    <dest />
</link>

<link type="">
    <options />
    <base />
    <target />
    <name />
</link>

I'm not sure if the use of an attribute is best here.  We could stick to
the use of <option /> here also.  With options "soft" and "hard" as
values.

Another thing to mention.  Presently i'm assuming you only want to use
soft (symbolic) links.  Should this be default?  I believe Neven
recently switched nALFS to that method.  The use of hard links is fairly
rare. (we should of course, still support hard links, i'm talking about
the default option if it isn't supplied)


>   mkdir

<mkdir />

<mkdir>
    <base />
    <dir />
</mkdir>

Will talk more about this when i get around to the base/dir issue.


>   permissions

<permissions>
    <mode />
    <src />
</permissions>

<permissions>
    <mode>
    <base />
    <name />
</permisions>

The use of <mode /> and <target /> instead of <name />|<src />, imho.

I actually had this wacked idea of using something like this;

<permisisons>
    <owner>
	<read />
	<write />
	<execute />
    </owner>

    <group>
	<read />
    </group>

    <other>
	<read />
    </other>
</permissions>

And also;

<permisions>
    <owner>
	<option>read</option>
	<option>write</option>
	<option>execute</option>
    </owner>

    <group>
	<option>read</option>
    </group

    <other>
	<option>read</option>
    </other>
</permissions>

May, make more sense.  I know this isn't exactly anywhere near standard.
However, it is an interesting way we could write permissions.  Dunno
what others will think thou.  I know you guys hate when you have to type
more then need be ;0


>   setenv

<setenv>
    <variable />
    <value />
</setenv>

I'm presently using this too, which was taken from nALFS.

I know there's been alot of talk about using a generic container like
tag with setenv, however i didn't follow that discussion that much, i'll
have to reread it again to get all the details... and see what happend
with it.  Personally i don't mind this method at all.

  
>   I've presently left out the prebuild/build/postbuild (setup/build/install)
>   untill we pick the best way to deal this this.  Allthough it would problably
>   be best to leave the use of them optional anyways. (ala target problably)
  
I'll have to reread all those thread that had to deal with this issue,
along with the <su> and user things.  Unless is willing to write me a
little summary :)

But for now, i'll not mention the "place holder" tags, they were only
mean't for that.. if we can find something better, let's use it.

>   Entities are totally optional.  However they can be quite usefull.
  
I've been getting the impression that alot of ppl seem to consider this,
so i've added a quick note.

You don't *have* to use entities.  They are juse nice sometimes.  Can
save alot of work.. unless i guess you are sed guru :)

Ok...

The dir, base discussion is going to start again.  Let's try and keep
this short however.

I am willing to use <base /> instead of <dir /> as a tag name.  I'm even
willing to keep the old style <mkdir>.  However mixing both <base /> and
<dir /> I cannot accept.  I'm sorry, it's just a little too confusing if
you ask me, especially to someone that's never used these profiles
before.

So.. Neven, Mark, Felipe, Jason, everyone else.. please post your
thoughs and suggestions.  I know i didn't list all the tags, these are
just mostly the ones i've been playing with.  Id like to get these done
before talking those ;)

-- 
Jesse Tie-Ten-Quee  ( highos at linuxfromscratch dot org )
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list