cvs commit: ALFS syntax.txt

Mark Ellis mark.uzumati at virgin.net
Wed Mar 27 13:55:35 PST 2002


On 2002.03.27 17:50 Jesse Tie-Ten-Quee wrote:
> 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 look forward to it :)

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

Takes deep breath....

> 
> >   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 ;)
> 

Personally prefer long forms wherever practical, xml is meant to be 
readable to a certain degree, so no point trying to take that away. 
Between archive and source, slight preference for archive.

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

Definitely dont like the use of option here, they aren't the same thing 
as the options in the file op handlers and should be differentiated.

> 
> >   make
> 
> <mkdir>
>     <dir />
>     <option></option>
> </mkdir>
> 
> <mkdir>
>     <base />
>     <dir />
>     <param />
> </mkdir>
> 
> Same as above.
> 

Ditto :)

> 
> >   execute
> 
> <execute>
>     <dir />
>     <command />
>     <option />
> </execute>
> 
> <execute>
>     <base />
>     <command />
>     <param />
> </execute>
> 
> Same as above.
> 

Ditto.

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

Oh i dont know, looks like a good place for a <base> :) Actually now i 
think about it it does ! How about :-

<remove>
   <base />
   <cant think of a name for this bit />
</remove>

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

Stick with param for the others, see above. Multiple tags for multiple 
options, sounds reasonable.

> >   move
> 
> <move>
>     <src />
>     <dest />
> </move>
> 
> <move>
>     <base />
>     <source />
>     <destination />
>     <options />  (i believe?)
> </move>
> 
> Same as above.
> 

Been here before :)

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

Jesse, dont know if you were listening in on your extended absence when 
we were discusing where to use elements or attribs. The whole thing 
sprawled over umpteen threads, but we eventually thought this was best 
as an attrib mainly 'cos it could be one of several (ie. 2) specific 
values rather than freeform content. There were other reasons too i 
think but this was a biggie.

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

Yep sym is default.

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

Got an <options> in there too, to create parent dirs if necessary.

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

Target could work.

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

Dunno, i can see where you're coming from and it has its good points, 
but it's definitely errm, expansive :)

> 
> >   setenv
> 
> <setenv>
>     <variable />
>     <value />
> </setenv>
> 
> I'm presently using this too, which was taken from nALFS.
> 

Dunno exactly what Neven is doing with this, but i treat an empty 
<value> as setting the var to a null, and no <value> element as 
unsetting the var.

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

Hey it was a blast, we came up with great ideas then realized someone 
had to come up with an implementation, gulp :)

> 
> >   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 :)
> 

Both of these points came up in that generic <stage> discussion. 
Personally i quite liked the idea.

> 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 ;)
> 

Assuming <base> refers to the directory from which all ops are 'based', 
the only common usage of <dir> i'm familiar with is in <mkdir> yes ? In 
which case, rename that <dir> as <name>, or even <target>, though i'd 
prefer <name>, you're making a dir so <name> shouldn't be ambiguous.

Stuff i've got that you havent, for whatever reason.

<chroot dir="...">
</chroot>

This one also came into the generic container thread.


<patch>
   <base />
   <param />
</patch>

Always considered patch a bit odd, 'cos without an "optional" param its 
useless. Maybe needs a rethink.


<search_replace>
   <base />
   <file />
   <find />
   <replace />
</search_replace>

Invaluable to all but the previously mentioned sed gurus :)


<textdump mode="append | overwrite">
   <base />
   <file />
   <content />
</textdump>

Default is overwrite.


Those last two in particular will probably start the <execute> vs 
specific elements thing again :) Depends what you're trying to achieve, 
either encapsulating shell commands in an automated build system or 
creating a build system with its own syntax. Both equally valid goals, 
personally i like specific elements.

What about <package> ?

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