Joey Hess wrote: > Philip Hands wrote: > >>Laying awake last night, it occurs to me that I could make my preseed setup >>much simpler if we added a small feature to the processing of >>preseed/include* settings. >> >>The idea is that we indicate in some way that the file retrieved should be >>executed, and it's output used as the preseed file, rather than the file >>itself. >> >>For example, we could treat filenames containing a pipe (|) as the last >>character as something to execute. >> >>So, taking an example from my preseed stuff, we might have: >> >> d-i preseed/include string chain_to_preseed2.sh| > > > Hmm, I'm not opposed to doing that, but maybe there is a way to > generalize it and make it more useful. > > One thing preseeders proably want to do is cause their own scripts to be > downloaded and ran to do arbitrary things (not just preseeding). The > early and late commands allow this, but they run into the same > scalability issues as include_command. And it would be a good thing if > there was a natural path from developing these scripts for preseeding, > to later including them in a udeb. Very true, things do seem to crystallise out as you play with these setups, so that certain reusable bits reveal themselves as being worth packaging. I really like the idea of being able to say "get and execute script x from wherever you got this preseed file". Presumably, with something like: preseed/execute which grabs a file and executes it during the preseed procedure. A way to then get back into preseeding would then be handy. We could certainly do the "STDOUT tells us what to include next" although I think that it would be nice to be able to execute a command that then started another bout of preseed including --- is the preseed setup supposed to be re-entrant at present? I get the impression (although I may have just missed the right way of doing this) that we could also provide some more ways of failures resulting in informative messages about what went wrong. At present, a typo in the downloaded scripts tends to tell you that you failed to download a preseed file IIRC -- fine for people that developed the preseed stuff, but not helpful for our users. > So maybe make the early and late commands be scripts downloaded same as > preseed files, and allow them to easily download other preseed files > too, from the same locations they were downloaded from. Yes, if we provided a command for doing that, then it could be invoked from inside the downloaded "script" -- BTW I don't think we should restrict the downloaded things to being shell scripts --- I don't see why people shouldn't be able to write programs in perl, C or whatever else they like (assuring they can get them to run in the d-i environment) and use them as the downloaded "scripts". > Maybe I'm overdesigning though, and I have no problem accepting your > patch in the meantime, if it works. I did notice that I was doing a lot of wgetting to make my stuff work. It would be much better to not have to worry about where the file was coming from, so I agree that using the same retrieval mechanism makes a lot of sense. Cheers, Phil.
Attachment:
signature.asc
Description: OpenPGP digital signature