On Mon, Sep 18, 2006 at 01:12:52PM -0400, Nathanael Nerode wrote: > <posted & mailed> > > Wouter Verhelst wrote: > > > On Tue, Sep 05, 2006 at 11:35:25AM +0200, Wouter Verhelst wrote: > >> Feedback is welcome. > > > > Since the only feedback I received thus far was Goswin von Brederlow > > saying he liked the idea, and since I didn't have much else to do today > > (other than wait for a supplier...), I went ahead and wrote it. It's > > committed to /people/wouter/customization-modules in d-i svn. > > > > It hasn't been tested at all yet (hence the commit to /people rather > > than /trunk), but this is mostly meant as a proof of concept anyway. I'm > > particularly not very happy about the way I currently "look" for usb > > storage devices (really all I'm doing is find any devices called > > /dev/fd*, or anything which is situated under /dev/cdrom/ or /dev/discs) > > > > Can people please have a look and comment? I'd like to avoid some > > specific GR by making whatever is going to be voted upon moot ;-) > > > > So I'm looking at how much of d-i is ready for multiple udeb sources.... > > Checking the net-retriver modules makes it clear that it ASSumes that > there's only one source. I'm not entirely sure how to disabuse it > of that assumption.
I've been thinking that the best way here is to just nuke the configuration of the retriever before (or while) running customization-modules in some way. We'll be assuming that there is at least one way to get udebs onto the running debian-installer session; so the assumption that udebs have been downloaded isn't totally unfair, and there won't be a need to download additional modules at that point anymore. At least I think so; would have to do a test run to be sure. > There's an easy way to do it: make a copy of net-retriever > (customization-net-retriever) > which instead of using the choose-mirror debconf information, prompts for > a URL (and *doesn't* cache it, so that it can be run repeatedly with > different URLs). > > I hate to duplicate code, but some of the net-retriever code (like the > signature checking) should be torn out for this purpose anyway, so this > is probably the way to go. Except that you'll inflate the initrd's by unnecessary amounts, which will make it harder to install Debian on RAM-limited machines. Clearly not the way to go. [...] > The other way is to make the net-retriever program handle both alternatives, > but if it's invoked from anna (as it should be), there's no way to tell it > which version is wanted, so I think that's not workable. > > I think maybe I should just write this now. Be my guest ;-) > ---- > If we use the more complicated anna-using version I suggested rather than > your very straightforward code, then for local disk udeb loading: > > floppy-retriever seems good to go; it even invokes mountfloppy, and > it doesn't need a Packages file or anything. Right. > This should be the model for other 'customization' retrievers. > > cdrom-retriever looks pretty much good to go as well, but it doesn't > similarly handle mounting and umounting, and it wants a fairly complicated > setup on the CD. So maybe it should be forked. The complicated setup isn't too big a problem; the mounting and umounting can be done from customization-modules. As above, duplicating code is a bad idea for d-i, and I'm not convinced here. > I believe the main customization menu is the > place to handle ejecting and replacing the installation CD (which is > clearly the Hard Part). > Why? Mostly because it has to be done for all > local media (CDs, floppy, USB stick, etc.), and will be done in > approximately the same way for each one: check whether the device is > mounted, umount if it is, do the work, remount it at the end. Right. > (Frankly I'm unsure how the multiple installation > CDs work now: I guess none but the first contain udebs.) Exactly. > I'm not *quite* sure how to write that code (everything else mentioned here > I think I could write right now pretty much). > > There is no usbstick-retriever or harddisk-retriever. There should be, for > reasons beyond customization disks: it's a little silly that those > options require an ISO image. :-) Couldn't agree more, but they're not as urgent as 'making sure it works'. > These should be substantially > simpler than cdrom-retriever or floppy-retriever. at least easier than cdrom-retriever, yeah. Hard to be simpler than a shell script that is 30-ish lines long. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
