cvs commit: ALFS syntax.txt

Lee Saferite dsaferite at yahoo.co.uk
Wed Mar 27 11:59:35 PST 2002


On Wed, 27 Mar 2002 09:50:35 -0800
Jesse Tie-Ten-Quee <highos at linuxfromscratch.org> wrote:

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

My vote would be for source and destination.  XML is not meant to make things smaller.  It's meant to organize things, correct?  It makes more sense to use a few more letters and gain some read-ability.

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

I think multiple <option> elements are a good idea.

> 
> >   make
> 
> <mkdir>
>     <dir />
>     <option></option>
> </mkdir>
> 
> <mkdir>
>     <base />
>     <dir />
>     <param />
> </mkdir>
> 

I would like to suggest
<mkdir>  (or whatever you want to call it)
   <base></base>
   <name></name>  (the name of the directory)
   <option></option>
</mkdir>


> >   execute
> 
> <execute>
>     <dir />
>     <command />
>     <option />
> </execute>
> 
> <execute>
>     <base />
>     <command />
>     <param />
> </execute>

I would like base, command, option

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

What about choosing a recursive/non-recursive remove of a directory?

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

  I would like the second one.  I'm guessing the <base> would only be used if the <source> or <destination> were a relative path?

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

> 
> >   link
> 
> <link>
>     <dir />
>     <src />
>     <dest />
> </link>
> 
> <link type="">
>     <options />
>     <base />
>     <target />
>     <name />
> </link>
> 

<link>
   <base></base>
   <target></target>
   <name></name>
   <option></option>
</link>

For some reason, <target> feels wrong as a name.
And I would think 'soft' is a best case default.



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

I like the second one.

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

Actually, I like the last idea, even if it is long.  Maybe add a mode attribute to permissions the indicate if how the permissions should be applied in relation the the current permissions. Add, Remove, etc.



As for <setenv>, <su>, <chroot> and any similar ones, I suggest:

<stage>
   <stageinfo>
      <name />  (this would be the only REQUIRED element of <stageinfo>
      <version />
      <user />
      <group />
      <root />  (as in, chroot)
      <env mode="set|add">
         <var name="" value="">
      </env>
      <base /> (the base for any element that needs a <base> tag but none was specified)
      or
      <defaultbase />
   </stageinfo>
   ...   (any valid elements under <alfs>, including <package> and <stage>)
</stage>

and for package:

<package>
   <packageinfo>  (REQUIRED>
      <name /> (REQUIRED)
      <version /> (REQUIRED)
      <base />
      ...
   </packageinfo>
   ... (any valid elements under <alfs>, including <package> and <stage>)
</package>

We could add a depends/conflicts section to the <packageinfo> element.  I wouldn't need to DO anything, but at least you would have the info.  Maybe in the future you client software would know what to do with the section.


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