New Features for Profiles
Kevin P. Fleming
kpfleming at linuxfromscratch.org
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