New Features for Profiles

Kevin P. Fleming kpfleming at
Fri Nov 26 12:15:08 PST 2004

Hui Zhou wrote:

> The way I did it is a --dry-run option which runs over all the elememts 
> without actually exec any real command except the download command. Each 
> handler will be passed with the dryrun option or replaced with a dry run 
> handler which does nothing for most elements; For stage, chuser, or 
> chroot, it tracks the default directory or user inorder to download the 
> package into the correct directory that the user would desire. I 
> wouldn't deny it is complicate to implement, but by using seperate 
> handlers, it appears quite clean.

And how do you handle users that don't exist, because they are created 
by the profile? How do you handle directories that don't exist, for the 
same reason? How do you handle directories that do exist, but the target 
user doesn't have permissions in the directory, because one of the steps 
of the profile would handle that change?

For that matter, how do you handle the fact that not only might the 
directory not exist, but its _parent_ directories might not exist, 
because they are created some package installed during the profile's 
execution? For sure, the current LFS profile does not have this 
situation, but the ALFS profile language supports it completely. If you 
implement some "dry run" method in nALFS that disallows the profiles to 
be constructed in the most efficient and/or direct way possible, then 
you've not actually improved the situation at all.

All of this technical discussion is moot anyway: if someone can provide 
a solid line of reasoning why the existing wget script and other 
documentation is not adequate for nALFS users to be sure that they have 
all the required packages available before starting their profile run, 
then _that_ is the problem that needs solving.

More information about the alfs-discuss mailing list