Re: common udpkg and uapt-get functionality
Anthony Towns wrote:
> (Some comments, take them how you like)
It's more or less what I've been thinking about.
> main-menu has (aiui) a list of all .udebs installed. The .udebs start
> off unpacked but not configured in general, they only get configured
> when the user selects a menu item, and the configuration is the process
> of answering the appropriate debconf'ed questions from the package's
> postinst.
Right.
> There'll be a handful of udebs already unpacked and configured: at a
> minimum the one containing the boot-floppies kernel that you just booted
> with, busybox.udeb and main-menu.udeb.
Right.
> If all the udebs that you might ever want are already unpacked, you only
> need to write to the debconf database (the answers to any questions need
> to be stored for backtracking), the udpkg database (so you know which
> packages are configured and which aren't for the main-menu), and the
> /target device. This might make boot-from-CD-no-drivers.tgz-no-nothin
> installs pleasant (since you'd just need a kernel, and a ro root
> filesystem on the CD).
Right, although it's a bit of a detour from the issues at hand I think
(plus packages may need to write data elsewhere as they are configured,
god knows what).
> Normal case though is that your floppy only had room for a few things,
> and you'll get the rest from CD, NFS, http, or so. In this case you'd need
> some sort of "enabling" udeb that lets you say:
> * I want to retrieve .udeb's from here
This is probably just chosing from a list of retreivers and then
optionally setting up the retreiver (if it needs to be set up and is not
already set up).
> * I want to retrieve all but the emacs.udeb (because I don't
> have time to d/load it)
I don't know how this step could be handled without exposing the
internals of the installer to the user. So I see little choice but to
disallow it and automatically pick what to retreive.
> and it would then go and download all those udebs, install them, and
> return to a new updated main-menu.
Main-menu will detect this and automatically update, FWIW.
> This would imply debconf/udpkg would have to be somewhat re-entrant.
Debconf is effectively reentrant (you can nest programs that use it, all
can talk to a single frontend).
udpkg ... well yuck. It would be a significant divergence from dpkg to
make udpkg re-entrant. This is something I hadn't considered. I think I
have a workaround though. Make the udeb that installs the other udebs
already be fully installed and configured.
So, the main menu will display it, but will not want to make it the default
menu item. However we can make it have a modtest script[1] that detects if
more debs are available, and if so, asks the main menu to make it the default
menu item.
When it is selected from the menu, it will be dpkg-reconfigured since it
is already configured. So no reentrancy isses.
I think that'll work and the extra flexability of the modtest script
will probably be useful.
> I think the "do udebs have to be installed to be visible to the user"
> question is the key here though. Seems a really weird thing to say yes to,
> but I can't see any reasonable way to implement it if the answer is "no".
This is something Glenn and I touched on in irc last week. An
alternative is that the main menu builds up a list based on Packages
files, not what is installed. Picking something retreives and installs
the relevant package(s). It seems to have a lot of difficulties though,
especially when you start thinking about ways the system could fail.
Only showing stuff on the menu that we know we have already retreived
feels much more robust.
--
see shy jo
[1] see doc/ui.txt
Reply to: