cvs commit: ALFS syntax.txt

Mark Ellis mark.uzumati at virgin.net
Wed Mar 27 14:42:24 PST 2002


On 2002.03.27 19:59 Lee Saferite wrote:

<snip>

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

Man after my own heart :)

<snip>

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

Do you mean a non-recursive remove of a dir containing something should 
fail with an error ?

<snip>

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

Depends how you think about it, the link is pointing to something so it 
has a target. I suppose you could instead call it a destination but i 
think i'd get that confused with the name of the link.

<snip>

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

This is definitely the best i have seen of this, get that man a beer !

> <stage>
>    <stageinfo>
>       <name />  (this would be the only REQUIRED element of
>                                                              
> <stageinfo>
>       <version />

Not quite sure what we'd use version for here.

>       <user />
>       <group />
>       <root />  (as in, chroot)

Sounds a bit like base, how about <setroot /> ?

>       <env mode="set|add">
>          <var name="" value="">
>       </env>

This in particular i like.

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

The whole stage thing is definitely growing on me :)

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

Can do, or we could even just leave it for now on the understanding 
we'll get around to it. Knowing us we'll just keep on adding.

<snip>

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