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

Re: common udpkg and uapt-get functionality



Anthony Towns wrote:
> 
> On Mon, Nov 27, 2000 at 07:55:59PM -0800, Joey Hess wrote:
> 
> (Some comments, take them how you like)
> 
> > We need a retreiver controller, but it does *not* need to look like apt.
> > I'm mostly concerned that we don't know how the retreiver controller is
> > supposed to work. Ok, it can download debs and tell udpkg to install
> > them. All well and good, but how does it know which debs to download?
> 
> 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.
> 
> 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.
> 
Plus you will need to have at least one fetch method on the disk, or no
further udebs will be able to retrieved.

> 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).
> 
> 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
>         * I want to retrieve all but the emacs.udeb (because I don't
>           have time to d/load it)
> and it would then go and download all those udebs, install them, and
> return to a new updated main-menu.
> 
This "enabling" deb could just be an empty package that has dependencies
couldnt it ? 

> This would imply debconf/udpkg would have to be somewhat re-entrant.
> 
Im not sure what you mean by this.

> 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".
> 

Do you mean visible to the user via the menu system ?

What if the control.tar.gz and data.tar.gz for udebs were seperated,
that way a disk could have heaps of packages control files from scratch,
packages could be configured without yet being functional. The installer
would at least know what its getting into before it tries to fetch the
rest of the udeb.

Of course there isnt as much value in configuring something that isnt
useable yet, just an idea.


Glenn



Reply to: