cvs commit: ALFS syntax.txt

Lee Saferite dsaferite at
Wed Mar 27 15:27:06 PST 2002

On Wed, 27 Mar 2002 22:42:24 +0000
Mark Ellis <mark.uzumati at> wrote:

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

I'm flattered. /me blushes

> > 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 ?
I'm not sure *I* know what I mean, Just that if you lump 'rm' and 'rmdir' functionality into one element, then you should have the ability to specify options, such as 'force' and 'recursive'.

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

Ok,  I'm a bit brain dead, It's late here (Luxembourg)  and I'm tired.  =)  I just can't make myself like the <target> element.  But I can live with it.

> > <stageinfo>
> >       <version />
> Not quite sure what we'd use version for here.

It's there because I was tired and didn't know WHAT people might want in a <stageinfo> element.  Mea Culpa  (is that correct?)

> >       <user />
> >       <group />
> >       <root />  (as in, chroot)
> Sounds a bit like base, how about <setroot /> ?

The name is not set in stone I think, just wanted to get the idea out for everyone. maybe <stageroot>  or <chroot> even.

> >       <env mode="set|add">
> >          <var name="" value="">
> >       </env>
> This in particular i like.

I read what was said about the setenv problem, and this is what I thought would work and be readable.  It's very easy to understand.

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

Any other takers?

With a <stage> element, we could address the stopping/restarting problems you have with <setenv> and get rid of container elements like <chroot> and <su>.  if you start at a random point in the process, it should be able to apply all the <stage> elements in order before running the selected element/elements.  Then you KNOW what your env/user/group/root would be at that point.  Also, the <name> element for the <stage> would make a display MUCH nicer.  I hated when Neven added <include> and the display in nALFS was always the filename.  I patched the <include> handler to let me set a 'display name' so I saw THAT instead of a filename.  that made me realize how nice it would be to group the steps in logical 'stages' and give the stages a name.  the rest (user, group, env, root) is just a logical extension of the grouping.

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

I've also worked out a way to handle depends/conflicts, I'll post is later.  It's similar to the <env> tag.

Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list