Re: Supporting multiple udeb sources.... is it really this easy?
On Wed, Aug 30, 2006 at 11:20:53PM -0400, Nathanael Nerode wrote:
> OK, looking through 'anna' (finally found it *$ing package which only produces udebs),
> it looks like it should *not* need to be modified.
>
> 'anna' can be invoked multiple times with different retrievers, which is all that
> is needed for this.
>
> (There may be some issue with Packages files. I'm not clear on this yet.)
>
> I believe support for installing non-free *debs* is already present, right? It's
> just non-free *udebs* we're worrying about. (If not, what needs to be done here?)
>
> A "retrieve from alternate CD" retriever is probably necessary, which would eject
> the CD, let you put another one in, install udebs from it, and then eject it and prompt
> you to put the original CD back in. Doesn't sound *too* hard.
>
> Now I have to find where anna is *invoked* from. Sigh... I am in a maze of twisty
> udebs, all different.... It looks like it's invoked from all over the place.
>
> It looks like all I need to do is write an "install-extra-udebs" module which
> places itself fairly early in the main menu, and asks "Do you want to install
> additional installer modules?"... (if yes) "With what retriever?"....(configure anna
> and the retriever, run anna with that retriever).
>
> What tricky bit am I missing?
Maybe some issue of dependencies not being easily fullfilled this way (as in
kernel modules depending on their respective firmware, and anna downloading
those automatically.
What i would like, is a firmware-loading module, which is run during or after
hardware-detect, but before the normal .udeb downloads, and which looks at the
devices installed on the system, compares them with a (downloaded) set of
devices needing non-free firmware, and then informs the user about those
cases, and ask him if he want to download those non-free firmwares and/or
modules.
Problems happen naturally with those firmwares needed to get access to the
external archive (on cd, usb or net), but these would need to be included in
the ramdisk image and not really concerned by this problem.
Another idea that has crossed my mind the other day, would be to create
separate initramfs images, one holding the main installer, the other holding
the kernel modules (would allow to keep a single copy of the installer, and
various copies of the per flavour kernel modules), and finally a third one
holding the non-free .udebs.
Since initramfs is only compressed cpio archives, it would be easy enough to
cat them together at image built time, or even to teach bootloaders to cat
various of them together.
This seems like an elegant post-etch solution to the d-i non-free firmware
image problem, but will probably be seen as more of me challenging the d-i
leader team authority and dismissed out of hand.
Oh well,
Friendly,
Sven Luther
Reply to: