directory-handling with nALFS
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Sun Apr 4 10:39:52 PDT 2004
> 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.
> By the way - I get the shellscripts and Makefile right from the book - I don't
> know what's the benefit on using profiles to get shellscripts.
People make ALFS profiles for things other than the book; many people
have heavily customized profiles for their system builds, and they may
want to export the relevant commands into a shellscript for some reason.
I don't ask why, if they want to do it more power to them!
> If you look at the provided patch, I didn't touch the permission code, so if
> the directory exists, but with different permissions, the handler will fix
OK, I had not looked closely at your patch; sorry for that.
> If you did not want to point out the handler-code, but the
> shell-script-handling, I only can reply the same, like you wrote in the
> hackers-guide to alfs:
> a function should do one thing and do it well.
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. If we applied
it to handlers, the stage and package handlers would need to be broken
up into many smaller pieces :-(
> - 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?
> - 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
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. To make the log
files more "expressive", we would have to add lines to the log for entry
and exit of every handler, with time stamps, and some way to mark the
system output from that handler. Once that is done, it might as well be
an easily parseable XML file instead of just plain text, there would not
be any particular advantage in sticking with plain text.
> - remote execution is already possible. Today. Just using ssh for example.
> I use it that way and it's ok for me. Why spending your valuable time on such
> an item?
I want to be able to support other frontends than just an ncurses-based
textual one. Jamie Bennett has already talked about working on a
gtk-based front end, and I can envision other ones as well. 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.
> I like to go out and enjoy the sun, riding the bike, ...
Me too, but I also get a lot of enjoyment from software development as
More information about the alfs-discuss