directory-handling with nALFS
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Tue Apr 6 18:49:03 PDT 2004
> 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
> 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