directory-handling with nALFS
bookreader at gmx.com
Sun Apr 4 11:40:36 PDT 2004
On Sunday 04 April 2004 19:39, Kevin P. Fleming wrote:
> Reinhard wrote:
> > On Saturday 03 April 2004 16:23, Kevin P. Fleming wrote:
> >>There are not currently any nALFS options (specified in nALFSrc) that
> >> change the execution behavior of the handlers, and I want it to stay
> >> that way.
> > Well, this tenor does not enable evolution, but OK, I bow to your
> > decision.
> It's not about evolution, it's about separation of responsibility. I
> have thought about offering a way for handlers to provide their own
> options, and will probably move in that direction, but not until after
> some more thought and discussion about how best to incorporate that into
> the configuration file.
Separation of resposability in the sense of modularization / object
orientation or do you mean personal responsability?
The second is sometimes very necessary, the former always a good point to
think about. A big switch I could think about is the general usage.
Like the 'use strict' in perl.
The difference in using it or not is quite as much as having 2 different
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.
> Actually that came from the Linux kernel coding standards, but I still
> agree. However, in this case "function" is referring a well-defined
> section of the source code, not an entire nALFS handler.
Don't stay so close to the word. I didn't cite you for reffering to the
handlers, but to the shell-commands.
I just transferred the meaning (I like the kiss-principle) to building
shellscripts or transform profiles.
> If we applied it to handlers, the stage and package handlers would need to
> be broken up into many smaller pieces :-(
I didn't talk about handlers or nALFS-functions at all!
> > - The userinterface is nice for testing, but nothing I really need (even
> > more as it is stil very unstable).
> Then don't run in interactive mode :-) If you don't need the nALFS user
> interface, is there any particular reason you are creating ALFS profiles
> instead of just going directly to shell scripts?
8-D Sometimes I ask the same to me. Why do I enter discussions, where I don't
use the result? Don't know. May be I'm some kind of special.
I had the Makefile/shellscripts working for weeks and already build a box with
lfs 5.1pre successfully.
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.
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
Primarily I wrote the script just for me, for my needs, to be able to build a
box in a nightly job.
When my box was done, I scanned the mailinglists and got some other ideas. I
like sw-development as you, so I thought, spent some little time and others
may benefit from your script.
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
It makes me mad, when I see, how users of the different LFS-sections work/
fight against each other.
For me, LFS is a very great idea and for me, it could be possible, offer
education and a stable and valuable os, which uses not only for kidding
May be I could move a bit with my blockhead :)
> > - logfiles should be clear and expressive. For me, using XML in logfiles
> > is an big overkill, which blow up the files unneccessary. Logfiles are
> > known to be big, so you have to deal with wrapping, versionizing and lot
> > of other things. If the entries are expressive, you could easy get the
> > information out using grep. If you have to deal with lots of logfiles,
> > one day you reach the point, where you like to learn perl and regex - and
> > then you get everything out of the logfile without having xml inside.
> > XML without any doubt has its benefit, but I don't need it anywhere and
> > everywhere.
> When the logfiles are converted to more fully utilize XML, they will be
> much more powerful than they are today, and much more powerful than any
> combination of grep/perl would be without a ton of work.
I'm not convinced. Every sysop works with "standard-tools" to get important
info out of logfiles and I know logging systems, which store the logs into
databases, or even use different machines for logging, ...
but I never heard about logging in xml.
Well, the only reason to do that (grunt?) work is for having a base for
uninstall features. But I think, it is worth to think about separation of
logs (i.e. compiler output) and *important* information (filenames,
> Remote execution will also support being able to "disconnect" from a running
> session and reconnect later to check on progress, which ssh can't easily
OK, you got me! - That's a great plan.
Normally you would detach your build-process and tail the logfiles. With that
you could also detach.
I think, we have a different focus.
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
More information about the alfs-discuss