New Features for Profiles

Hui Zhou zhouhui at
Fri Nov 26 15:16:21 PST 2004

On Fri, Nov 26, 2004 at 01:15:08PM -0700, Kevin P. Fleming wrote:
>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.

We are talking about download the packages and relative patches, 
right? The common practice in my mind is the user would like to put 
all the downloaded packages in one directory or two that accessible 
both in the first stage and in the chroot stage, in which create the 
relative directory path and use it during dryrun works alright. If the 
profile is writen in such a way that the package is supposed to be 
downloaded at build time and deleted afterwards, predownload all the 
packages doesn:t make sense so the user won't dryrun it anyway.

So the dryrun never will restrict any type of profiles that the 
current nALFS allows, just for some profiles the dry-run option just 
doesn't apply and it is not difficult to detect these situation and 
emit error when the dryrun is invoked. 

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

Each profile is strongly linked to a specific set of packages by 
nature or it won't finish the build. So if the solution is to use wget 
script, I would recommend a way to bundle the wget script with the 
corresponding profile so one would only download both. Or better yet, 
add a tag in the profile to encapsulate the wget script. As the url 
info is already embeded in the profile, the wget script seem a little 
be duplicate.

I havn't really tried the nALFS yet, the only obstacle being I 
downloaded the profile but too lazy to find the corresponding wget 

>Unsubscribe: See the above information page

Hui Zhou

More information about the alfs-discuss mailing list