LFS profile using the new syntax

Mark Ellis mark.uzumati at virgin.net
Thu Oct 25 14:57:41 PDT 2001

On 2001.10.25 16:27 Neven Has wrote:
> On Tue, Oct 23, 2001 at 11:22:30PM +0100, Mark Ellis wrote:
> > Hi Neven, looks nice, hope we get a bit of discussion going on this, so
> far
> > it's been difficult to get anyone to bite :)
> Yes, that would be nice. :)
> > 2) With links, type still seems more natural as an attribute rather
> than an
> > element, since it has only specific values, what do you think ? I
> suppose
> > it really doesn't matter all that much either way.
> Heh, I actually move it to an element just a day before I sent the
> profile. :)
> Same goes with "name" and "version" from <package>. I moved them because
> there
> could be more interesting package info added latter (like "url" for 
> example)
> so it wouldn't look very nice in an element.
> And then I moved "type" from <link> because it was the only element left
> which contained attributes (not counting <alfs> and <chroot>). But that's
> not a very strong reason, so I'll just bring it back as an attribute.
> > Also, passing -f in a
> > param doesn't seem right, maybe we should have another attribute or
> element
> > for force. I dont think we want arbitrary command parameters except
> where
> > strictly necessary. Then again i suppose there is the nightmare of
> patch if
> > we go down that path.
> I agree, but the problem with this is - there are a lot of parameters
> which
> would need a new attributes (I look at <patch> as a
> has_to_be_a_system_command
> so I don't count it here). For example: -p for mkdir, -a for copy, -f for
> link
> etc. etc.
> OTOH, we could always add new attributes latter, without making the new
> syntax
> incompatible with the previous (very important of course).
> So we might as well start doing that now.

I know what you mean, there are a lot of possible parameter options.
something specific got me thinking about this, and i'm assuming nALFS calls
mv, cp, etc via the shell, I still havent got around to looking through it
:) If this is the case, all those parameters are fine. If however you have
an implementation like the perl FE_BE, copy's and move's are done
internally, so an -f flag for example is meaningless unless you reimplement
the system commands. Dunno where to go with this really, maybe we'll have
to come up with standards as to what an implementation should be capable of

> > 4) <base> is fuzzy, how about <dir>, and use <target> as the directory
> to
> > be created in <mkdir> ?
> I wanted it to be a bit more self explanatory. I agree that <base> is not
> the
> best solution (and not even very self explanatory now that I think about
> it
> again), but <dir> doesn't say much neither.
> That should be a directory which we immediately change to, so maybe
> something
> like <current>, <current_dir> or... just <dir> ? ;)

<current_dir> is cool, or <working_dir>, the world is our giant clam, or
any other mollusc of your choice :)

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