newbie ?

Eric Miller emiller at techskills.com
Thu Mar 28 17:16:36 PST 2002


I have been following this group for months now, trying to decide if LFS is
over my head.

I am intermediate Linux user, have built a Beowulf cluster and now am
considering LFS.

Are the docs complete?  Any advice on hardware platform?  Am I crazy for
considering this?

-----Original Message-----
From: alfs-discuss-bounce at linuxfromscratch.org
[mailto:alfs-discuss-bounce at linuxfromscratch.org]On Behalf Of Neven Has
Sent: Thursday, March 28, 2002 6:09 AM
To: alfs-discuss at linuxfromscratch.org
Subject: Re: cvs commit: ALFS syntax.txt


Apologies if I'm repeating something somebody already said or suggested
(or repeating myself for that matter). I'm lost in these e-mails. :)

On Wed, Mar 27, 2002 at 09:50:35AM -0800, Jesse Tie-Ten-Quee wrote:
> <unpack>
>     <src />
>     <dest />
> </unpack>
>
> <unpack>
>     <archive />
>     <destination />
> </unpack>
>
> Here, it's more about what makes more sense i guess and comes down to
> personal preference.  Id feel better if someone suggested two better
> names for these tags.  I'm more or less torn on this issue.  However i
> guess the use of <source /> and <destination /> would make alot of
> sense. (even if it is longer to type out ;)

As other have already said, using longer and more descriptive names is
probably better. Also, I prefer <archive> here. "Unpacking source"
is a bit confusing - "source of what", could be asked.
"Unpacking the archive" seems logical.

> <configure>
>     <dir />
>     <command />
>     <option />
> </configure>
>
> <configure>
>     <base />
>     <command />
>     <param />
> </configure>
>
> The only difference here, is I started to use the <option /> tag instead
> of <param /> which i got from the idea of <options /> which is being
> used in nALFS for <copy /> and so forth.  I think it's little nicer
> then <param /> and makes a little more sense, imho.

[ I have just read Mark's new mails. Oh well, here we go again... :) ]

The problem is a big difference between <options> from <copy>
and <param> here.

Here, its content is just appended, independently of parser and the way
it's implementing the handlers.

But with <copy> and others, it not just blindly appended to the
command. Since the parser doesn't have to use cp (for example) and can
implement that command itself, it _recognizes_ the options and act
accordingly.

So, I don't think that it's good to use the same tag. I like tthe <option>
idea for <copy> (see below), so I would use something different here.

I'm OK with <param>, although a better name wouldn't hurt. A full
<parameter> would be OK too (and I don't mind typing more here, if
element names will be more descriptive).

> <copy>
>     <src />
>     <dest />
> </copy>
>
> <copy>
>     <base />
>     <source />
>     <destination />
>     <options />
> </copy>
>
> Similar to unpack.  However if we use <option /> with configure and make
> (and other tags), the usage of <options /> may seem confusing.  It may
> perhaps make more sense to just use <option /> also, while allowing
> multiple tags. (so if you need say resursive and resursive, you have
> two options, one for each)

I think that using multiple <option> elements here is a good idea, much
better then something like "<options>recursive preserve</options>" that
we're using now. It's nice and clean.

> <link>
>     <dir />
>     <src />
>     <dest />
> </link>
>
> <link type="">
>     <options />
>     <base />
>     <target />
>     <name />
> </link>
>
> I'm not sure if the use of an attribute is best here.  We could stick to
> the use of <option /> here also.  With options "soft" and "hard" as
> values.

Since no multiple types will ever be needed, I wouldn't change the way
it's done now. Also, "option: symbolic" can be confusing. "Symbolic" is
not an option, it's a type. :)

> Another thing to mention.  Presently i'm assuming you only want to use
> soft (symbolic) links.  Should this be default?  I believe Neven
> recently switched nALFS to that method.  The use of hard links is fairly
> rare. (we should of course, still support hard links, i'm talking about
> the default option if it isn't supplied)

The only reason against using symbolic links could be ln(1), which
defaults to hard ones. That could confuse people which got used to it.

But since symbolic linking is used so much more, it will save us a lot
of typing and thinking if it's used as default. So I'm for it, yes.

> <permissions>
>     <mode />
>     <src />
> </permissions>
>
> <permissions>
>     <mode>
>     <base />
>     <name />
> </permisions>
>
> The use of <mode /> and <target /> instead of <name />|<src />, imho.
>
> I actually had this wacked idea of using something like this;

<snip>

> And also;

<snip>

> May, make more sense.  I know this isn't exactly anywhere near standard.
> However, it is an interesting way we could write permissions.  Dunno
> what others will think thou.  I know you guys hate when you have to type
> more then need be ;0

Well I like the idea of generalizing <permissions>, but there must be a
simpler, and a bit shorter format. Maybe something with using attributes?
I haven't give it too much thought, so no ideas here.

> <setenv>
>     <variable />
>     <value />
> </setenv>
>
> I'm presently using this too, which was taken from nALFS.
>
> I know there's been alot of talk about using a generic container like
> tag with setenv, however i didn't follow that discussion that much, i'll
> have to reread it again to get all the details... and see what happend
> with it.  Personally i don't mind this method at all.

I thing that <setenv> is much more natural being a container.
Using a generic one is a different story (discussed elsewhere).

> I am willing to use <base /> instead of <dir /> as a tag name.  I'm even
> willing to keep the old style <mkdir>.  However mixing both <base /> and
> <dir /> I cannot accept.  I'm sorry, it's just a little too confusing if
> you ask me, especially to someone that's never used these profiles
> before.

Yes, I agree. We seem to got used to it too much, so we don't even notice
how confusing it actually is.

Anyway, the place this issue is most visible is <mkdir>, so we could use
it as an example.

I like having two separate elements for the reason we already discussed
once - it saves a lot of typing when multiple directories, with the same
root directory, are being created.

So I would vote for leaving the _structure_ the way it is now, and only
rename the elements. <name> (as suggested elsewhere) might be a good
idea. <root> or <dir> instead of <base> are options too.


Neven

--
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message

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