[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

  * 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

  * 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: