cvs commit: ALFS syntax.txt
mark.uzumati at virgin.net
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
> > > 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
> > =) 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
> > <chroot> and <su>. if you start at a random point in the process,
> > 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>
> > 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
> > THAT instead of a filename. that made me realize how nice it would
> > 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.
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>
> > > > I wouldn't need to DO anything, but at least you would have the
> > > > Maybe in the future you client software would know what to do
> > > > the section.
> > >
> > > Can do, or we could even just leave it for now on the
> > > 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 linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss