Joey Hess wrote: >>%%% Ok, here's the heart of the matter. >>%%% First we have a new URL (this, I can imagine yo finding somewhat >>%%% upsetting ;-) >>%%% The idea is that if you specify an include file with a URL like: >>%%% dsd://foo/bar >>%%% It will atempt to get it from >>%%% http://debian-dsd-preseed.$domain/d-i/foo/bar >>%%% ($domain being the value of netcfg/get_domain) >>%%% failing that (i.e. there is no such server set up) it will get it from: >>%%% http://svn.hands.com/d-i/foo/bar >>%%% having tried this once, it will remember which succeeded, and stick with it >>%%% Obviously, on official CDs, that svn.hands.com name should be set >>%%% to an appropriate debian.org host. > > > Ok, seems clearly not suitable for general d-i to me. I take it that it's the made-up URL bit of that you don't like? I cannot say I like it myself much, but it was a way of saying "get this from the place where the preseed files were based". That's not as simple as just having a variable to hold the URL, since you need code to choose between copying the files off of a USB stick, and wget-ing them from an HTTP server since I want to be able to write recipes that are agnostic about where they are residing. Of course, since going down this route, I've also created a script (dsd_fetch_file) that includes the fetching code from preseed to allow scripts to easily grab files from the same source as the preseed files -- I think if we split the code in preseed out into a fetch_file script which was then invoked by preseed.sh and also available for scripts, the need for the horror of dsd:// urls might well evaporate. The optional nature of the dsd:// thing, as well as the optional preseed files, were both the result of thinking that one might want a central repository with a few locally hosted configureation files -- I've since come to the conclusion that you'd need to be an idiot to rely on a central repository if you were serious about auto-installing, in which case the need for both these has features probably disappeared as well -- I'll try rewriting things so that I'm not using either. ... > So, optional files: > > - Don't like the "?" and the end of an url since a valid url might > possibly have a good reason for ending with a literal "?". > - It seems to me that it cause issues with network robustness, having > a file get skipped if the network happens to glitch and it's marked > optional doesn't appeal. I agree, I always thought the problem here would be when the file exists but you don't get it anyway, resulting in a surprisingly uncustomised install. > Executed files: > > - Slightly in favour of adding this feature, although I expect it will > be used rarely, and I'd really rather see people making udebs when > they need to customise the installer to the extent this can afford. > > I'm not sure about having the output of the file be a preseed file. > Why is it better to have a script that does this: > > echo "d-i foo/bar string baz" > > Rather than: > > debconf_set foo/bar "baz" debconf_set does not allow you to set variables that don't already exist. *light bulb blinks on overhead* Hmm, I feel that it's possible that I've been spending quite a lot of effort working around that little fact, and that I should have just implemented something to setup new variables instead. > Doing the latter would make it easier for users to start out perhaps > as one of these scripts, and eventually package it up into a udeb > without having to rewrite it all. True. > Of course if this is done as just a script that gets downloaded and > executed, there's already a way to do that in preseeding: > > d-i preseed/early_command string wget http://url/script.sh ; sh script.sh Yeah. The thing that ended up getting messy (but this is perhaps because I didn't know what I was up to when I started out with this) was having scripts that then wanted to set up preseed values that then needed to be used by other scripts that were only being invoked depending on the values that had been set. The implementation of classes with dependencies (i.e. classes that can imply other classes, recursively) got massively cleaner once I had executable preseed files. > But this has the issues of needing to have the url hardcoded instead > of fetching from wherever the preseed file came from, and of having > fairly crap error handling. We could do something like this to get > the best of both worlds: > > d-i preseed/run_script string script.sh > > Which would be run as soon as the preseed file containing it was > loaded. I think that would probably be enough for my needs -- I think I'll patch preseed to provide this and see if I can rejig everything without losing anything. This has been very enlightening, Thanks :-) Cheers, Phil.
Attachment:
signature.asc
Description: OpenPGP digital signature