debconf apt configurator
Joey Hess <joey@kitenet.net> writes:
> Here is a first stab at such a UI. I am using debconf as the frontend to it,
> which means it can have a variety of looks and feels, including a dialog ui,
> like Adam wants. To take a look at it:
[...]
> It currently handles http and ftp well; cdrom, nfs, and a mounted filesystem
> need to be fleshed out. It asks if you want non-free, and if so, if you want
> contrib. Then it lets you pick from a list of countries, and choose from a
> list of mirrors in the country. It finishes by spitting out an apt.sources
> line. There is also provision made for entering mirror data manually.
Okay, sounds good for the network part. Regarding CD-ROM, I think it
should *first* check in some reasonable locations on whether a CD-ROM
is present. I've CC'd <debian-cd>, perhaps they can give us some
clues on platform-independant ways of doing this. I would suppose
checking for ISO filesystems and well-known top-level files which
appear on the CD in well-known devices locations, such as /dev/hdc,
/dev/cdrom, /dev/scd[01]. I wouldn't think it'd be *too* hard to do
this. A fallback would be to ask for the device where the CD-ROM is.
This whole "autosense" scenario, if doable, is attractive to me
because then we could conceive of an automated installation media
detection for a great number of cases (probably 90% of CD users).
Now this system would also have to deal with the CD ordering issues,
if any; again, I look to <debian-cd> to offer guidance here.
So assuming the autosense fails, perhaps then we would ask whether to
use:
* network (see Joey's stuff)
* CD-ROM in a location not autosensed, which would prompt for mount
point(s). It should test that this is valid.
* NFS (could we inherit the location of the server used for TFTP in
case of that install method?), which needs 'server:share-name' and
possibly 'subdir/in/share'. It should test that this is valid.
* local disk, which needs 'device-name' and possibly
'subdir-in-partition'
* floppy (don't use apt at all, just emit a big ole' warning)
One nicety would be overlaying network stuff over possibly staler
CD-ROM archives, etc., but that's just fluff at this point.
> Using debconf for the frontend might be controversial, but I think it can
> handle all the types of prompting we might want to add to this, except
> perhaps ordering a list of sources be priority, which I doubt we want to
> trouble people with anyway.
Well, its only controversial in that debconf would have to be added to
base. What do you think of that? Are there any non-base depends that
debconf has?
> One nice features comes to light if you test it with this command:
>
> make clean test FRONTEND=dialog PACKAGE=aptconf PRIORITY=critical
>
> That makes it skip some of the less important questions, which happen to be
> those RMS wouldn't like and those I don't think we should trouble a newbie
> with. :-)
That is pretty sweet.
--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
Reply to: