cvs commit: ALFS syntax.txt
dsaferite at yahoo.co.uk
Wed Mar 27 15:27:06 PST 2002
On Wed, 27 Mar 2002 22:42:24 +0000
Mark Ellis <mark.uzumati at virgin.net> wrote:
> On 2002.03.27 19:59 Lee Saferite wrote:
> > 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 linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss