cvs commit: ALFS syntax.txt

Mark Ellis 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:
> >

<snip>

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

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.

<snip>

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

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

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

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

Mark
-- 
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 mailing list