On Tue, Nov 28, 2000 at 03:01:29PM -0800, Joey Hess wrote:
> Anthony Towns wrote:
> > 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).
I don't think they will: if you just blithely declare that .udebs can't
write to anywhere but, say, /var and /target from their maintainer
scripts, you can probably cope (/var being mounted as a ramdisk,
presumably). But yes, it's a complete digression.
> > 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).
Yup. You at least want to be able to indicate "Yes, I want to use this
retriever" (since bandwidth might be too expensive to get stuff via the
network, or the CD might be out of date and you want to use the latest
installer stuff, eg) and "You can access my mirror here" (since this is
probably not a good thing to just guess in many cases).
> > * 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.
Well, if you always download and install *all* .udebs, you can't
permit .udebs to ever conflict. Don't know that this is necessarily a
bad thing, but it might be if, say, nvi.udeb and vim.udeb both try to
install [/usr]/bin/vi.
> > 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.
Yup, figured.
> > 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.
Definitely. How about this?
* debconf runs main-menu.config
* main-menu invokes udpkg --configure http-retriever
* postinst invokes debconf to get info
* postinst writes
http-retrieve install-base
http-retrieve setup-grub
...
to /var/run/main-menu-retrieve
* postinst ends
* main-menu reads from /var/run/main-menu-retrieve
* main-menu iterates through, invoking the http-retriever,
and udpkg to unpack the retrieved udebs
It's something of an update-menus style solution but without the hackery.
If udebs don't ever have preinsts, they don't ever need predepends
either, so you don't need to order the unpacking, just the configuring.
> Make the udeb that installs the other udebs
> already be fully installed and configured.
Maybe the above would work instead? Or as well?
> > 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.
Agreed.
Another fun use case:
* debconf invokes the slang frontend
* debconf runs main-menu.config
* main-menu runs udpkg --configure http-retriever
* main-menu retrieves and unpacks fb-frontend.udeb
--- something somewhere happens, but what?
* debconf kills off the slang frontend
* debconf invokes the frame buffer frontend
* main-menu continues...
And presto we have a graphical (or web based, or database controlled,
or..) install...
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgplcC1T180wq.pgp
Description: PGP signature