cvs commit: ALFS syntax.txt
mark.uzumati at virgin.net
Thu Mar 28 02:25:20 PST 2002
On 2002.03.27 23:27 Lee Saferite wrote:
> 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:
> > > What about choosing a recursive/non-recursive remove of a
> > >
> > Do you mean a non-recursive remove of a dir containing something
> > 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'.
Sounds reasonable, i guess this is mostly used for removing build trees
so up 'til now its just been "scrap the lot no matter what", and force
hasn't been a problem 'cos we've been running as root. That will of
course change with all the <su> stuff.
> > > <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?)
Dunno, never knew what people meant by that anyway :) Nothing wrong
with version there, just can't think of a use for it at this moment in
> > > <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.
I think this needs something that leaves no doubt this is a change of
the root of the filesystem, rather than a default <base>. I don't
normally like naming things after their shell counterparts, 'cos those
names are sometimes a bit obscure :) but maybe <chroot> is best in this
> > > <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
> > > 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>.
Just o emphasise, this could include *build too :)
> 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
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