On Fri, Jan 12, 2001 at 01:41:38AM -0800, Joey Hess wrote:
> The requirements:
> * The modules will be split amoung a number of udebs, and some of them
> might be on a remote mirror and be downloaded during the installation
> process.
AIUI, udebs can't conflict: with each other; so these udebs will all have
to be able to be installed simultaneously. Maybe they should be handled
similarly to alternatives? (ie, they install into /lib/modules/2.4.0-udma,
and /lib/modules/2.4.0 becomes a symlink to that?)
> * We need to support flavored kernels (probably).
Possibly not, though. If we separate the kernel used for the install to
the one later used for booting, we don't have to have ext2 or reiserfs
compiled into the install kernel, nor do we have to worry about the size
of the boot kernel.
If we could do away with flavoured kernels entirely it'd probably make the
install a bit easier (don't have to work out which kernel's right for your
system in advance), and would mean we'd just need one set of modules, etc.
> * When the package builds an image, it is provided with a kernel.deb package
> somehow. As part of the build process, it pulls that deb apart, and
> pulls the modules out of it and creates the module udebs it needs. It
> also grabs the vmlinux file of course.
Or someone could just make kernel-image-udeb packages at the same time
they build the real kernels. You'd probably have to do this if you wanted
to separate the b-f's kernel and the real kernel.
> * If someone wants to do a custom kernel, they can provide the .udebs to
> the installer on floppies or some other local media.
Or use loadlin with a kernel-less root.bin, or setup lilo or similar...
> * Something or other can record the name of the kernel .deb package that
> all this was built from, so Aj's base building code can
> download/install it along with the rest of the base system.
Or I can grep the udpkg status file; or someone else can do that and
use the result as the default when asking what kernel image to install.
> * What about users who want to provide their own kernel, but don't
> have a debian system to build it on? They could just compile modules
> in, but there might be dependany problems then, if udebs depend on
> a particular kernel module udeb, and it is not available.
Is there any point adding dependencies? If the modules are available,
they'll have been unpacked already anyway... If the faux-alternatives
thing is happening, the /lib/modules/2.4.0 -> 2.4.0-foo link may as
well have been setup at boot time anyway (since it depends more on which
kernel you're running than on which modules you install), loading the
the specific modules you need can't be Depend'ed on anyway, which only
leaves running depmod, I guess.
So we can probably do without the dependencies. We might need to add
a non-interactive postinst that runs depmod, and make sure anna/udpkg
always executes non-interactive postinsts asap.
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:
pgpnhhtT48rFn.pgp
Description: PGP signature