directory-handling with nALFS

Kevin P. Fleming kpfleming at linuxfromscratch.org
Tue Apr 6 18:49:03 PDT 2004


Reinhard wrote:

> Separation of resposability in the sense of modularization / object 
> orientation or do you mean personal responsability?

The former; it really doesn't make sense for the frontend to know 
anything about the specific functions that the handlers perform, and I'm 
moving towards removing that specific knowledge from the backend too. If 
you have the time to compare CVS HEAD against 1.2.2 you'll see what I 
mean; much code has been removed from the nALFS core, the XML parser and 
and parse-tree builder that belonged in the handlers themselves.

Also, I really, really, really don't want to make a profile operate 
differently (i.e. produce different results) based on settings outside 
the profile. Someone should be able to take their profile (with its 
entity files), run it through xmllint --postvalid --noent and be able to 
see _everything_ there that will affect what the profile actually does 
to their system. Putting options into nALFSrc could set a bad precedent 
for causing handlers to act differently even though the profile has not 
changed.

> I don't care where or how this could be established. I thought, nALFSrc is for 
> the general behaviour of nALFS, so it seemed appropiate to me.
> But it could be put in the config-section of an profile as well. 
> No prob at all.

Right, that's what it should be. Either an entity that can be used when 
necessary, or something else along that line. That way the profile (and 
the behavior) are still defined by the elements in the profile itself.

> But I like the idea of the books and I like the comunity. I don't like some 
> guys looking down to others and blaming them out, but I've a thick skin, so 
> I'm stil here.

There has definitely been some of that lately, but things are starting 
to get better. Thanks for sticking with it.

> As I like to go out and enjoy the sun, I thought, editing profiles is not that 
> famous, may be, the editors like it, if the profiles could be created by a 
> nightly job and they could dedicate themselves to something more 
> enjoyable ...

Possibly, although even the existing profile has bits and pieces that 
are not in the book, or could not easily be translated directly from the 
book. Some of those may be indications that the book could use more 
configurability, but I suspect the official profiles will always have 
some differences from the books just to take advantages of the ALFS tools.

> At first contact I thought - what's that ALFS.
> Isn't there enuf build-tools like make, ant and the countless IDE's?
> But with the mail-archive I found ideas, I liked and therefor I choose to work 
> for ALFS.

And I thank you for it, more people involved produces a better product.

> My focus is to get a reliable system in the mean, that every build-run will 
> lead to the same result and I think your (not personally) focus is the ease 
> of usage?

Yes, but we also have a primary goal just like yours; running any given 
profile through nALFS should always produce the same results. However, 
that is easily achieved, as you have already explained: Makefiles can do 
it, shell scripts can do it, etc. nALFS goes beyond that to give the 
user a more useful interface to control and monitor the profile 
execution, and will eventually give them the ability to analyze the 
results at a great level of detail.



More information about the alfs-discuss mailing list