cvs commit: ALFS syntax.txt

Neven Has haski at sezampro.yu
Thu Mar 28 03:09:42 PST 2002

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.

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

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

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


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