cvs commit: ALFS syntax.txt
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
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 linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss