My newbie detailed analysis of the profile

Simon Perreault nomis80 at
Thu Sep 7 10:25:08 PDT 2000

On Thu, 07 Sep 2000, Thomas 'Balu' Walter wrote:

> > I didn't see a need to use similar names for the tags, as their use will not be
> > even close to similar. In fact, naming them completely differently will force
> > people to think about the differences between them.
> local values might be used as environmental-vars...

You're right. Then I prefer your method of having a single variable tag and
it's local/environment property defined by an attribute.

> > This way, the front-end could present the descriptions of the variables, and
> > the user could change the default value. Variables without a description
> > attribute would be considered as being non-optional.
> non-optional if the description is missing? I don't understand what you
> want to do here.

I still understand what I meant, but I was being stupid. Forget all about it.

> It describes that the following document is an ALFS-one. Perhaps we
> should even do an:
> <alfs version="0.1b"> So that the profilers can differ between them "Hey
> I don't know how to handle that profile - it's too new" ...

Great idea!

> > 
> > Why so? Why do we need a <defaults> tag? What's the use? Shouldn't we use
> > <!-- defaults -->
> > instead? I saw many tags in the profile that could/should be replaced by
> > comments. When a tag has no use, it doesn't need to exist. And I see no use to
> > the <defaults> tag. Please enlighten me.
> It is meant to structure the profile - the profiler knows that the
> defaults start here and end there.

What's the point? You're declaring simple local variables. They're already
defaulted. Why do we need to tell the profiler "These are defaults"? The
profiler would reply: "Hey, I know, I'm not stupid".

The point is that this <default> tag is primarily a comment whose purpose is to
structure the profile not for the profiler, but for the human who might be
reading it. In this case, a <!-- defaults --> comment would be more appropriate.

> > 
> > Couldn't that simply be replaced by a <mkdir dirs=$mountpoint> ? We have to
> > keep the number of tags to a strict minimum. If a tag doesn't do anything
> > differently than another tag, then it has no reason to exist.
> This is to give the compiler a chance to choose between using commands,
> or functions that each language has - e.g. <delete_file> could be done
> with "rm -rf" or unlink() in c...

I know about that, and I was trying to keep that in view while writing my
analysis. (That's why you use <rm>dir</rm> instead of <command>rm
dir</command>, we're not writing shell scripts, we have to abstract the
functions.) I'll ask a question: how is the <create_mount_point> tag any
different than a <mkdir> tag? Will C use two different functions? Will any
other language use two different functions? I don't think so. So this is an
unneeded tag.

> man ln :)

I read the man, and I don't get your point. I still think my definition of
"source" and "destination" was right. And anyway, the way shell command behave
is one thing. Maybe other languages do things the other way. We're trying to
abstract the meaning of each function, and I think the "to" and "from" I
proposed were more meaningful. Please explain in more detail, I may be stupid.

> The profiler has to know where each section starts - you would not have
> to use <title> in html though.

That's the whole question: why does the profiler need to know where each
section start?

> The version is not only needed for upgrading purposes but also for
> checking dependencies and such.

Right, dependencies!
/me blesses the <version> tag
That's not worth anything, though. More like a curse...

> I agree with you here... not dumb. but we should not use that for
> commands like mkdir, cd, rm,...

Exactly, because C will not call the rm program to erase a file. (that's only
an example).

> is there a tag that describes the architecture that package is meant to
> run on?

Well, since when you're installing a profile, all the package need to be
compatible with your architecture, an <supported_architectures> tag should be
included at the top of the profile, and should describe all the architectures
that are known to run ALL the packages. Or maybe we could use the contrary, but
we need that sort of tag.

> newbies are the best source of ideas for a new product.

I feel needed. Sweet feeling...

-- Support your government, give Echelon / Carnivore something to parse --
classfield  top-secret government  restricted data information project CIA
KGB GRU DISA  DoD  defense  systems  military  systems spy steal terrorist
Allah Natasha  Gregori destroy destruct attack  democracy will send Russia
bank system compromise international  own  rule the world ATSC RTEM warmod
ATMD force power enforce  sensitive  directorate  TSP NSTD ORD DD2-N AMTAS
STRAP warrior-T presidental  elections  policital foreign embassy takeover

More information about the alfs-discuss mailing list