cvs commit: ALFS syntax.txt

Mark Ellis mark.uzumati at
Fri Mar 29 02:50:32 PST 2002

On 2002.03.28 11:09 Neven Has wrote:
> On Thu, Mar 28, 2002 at 12:27:06AM +0100, Lee Saferite wrote:
> > 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'.
> I agree. "recursive" would be a good thing with <remove> defaulting to
> a "not recursive" mode.

Yep, ok, makes sense.

> > > > 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.
> Using the same names as GNU programs (their man pages actually) might
> shorten the learning curve for people got used to it.

GNU and man pages in the same sentence, not often that happens :)

> > 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.
> Nice.
> We should just improve the format and names a bit (IMO), but the whole
> idea is good.

The names could use some work, but i think that particular structure is 
a good way to go. If we want to thrash this out i think a new thread 
just for <stage> is in order, this is getting heavy.

> > > > 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.
> Heh. I can already see a new improved syntax coming after we agree
> on this one. Maybe we should improve handling of different syntax
> versions in the parsers instead. ;)

Arrgh, i just got rid of one alternative syntax :) Talking of which, i 
assume from the lack of response from a couple weeks back that no one 
is familiar with entity handling in XSLT ?

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