directory-handling with nALFS

Reinhard bookreader at
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 
enjoyable ...

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 
for ALFS.

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, 
system-changes, ...)

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

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 
of usage?

Kind regards


More information about the alfs-discuss mailing list