hi, On Thu, Sep 11, 2008 at 07:50:35PM +0200, David Paleino wrote: > > You’d run into the same issue as module-assistant has: a package being > > installed cannot launch installation of other packages. > > Uhm, right. > I believe there could be a margin of improvement here for apt-get: <snip> > 3) the postinst hook sets an "APT flag" (something like: "please rerun because > you still have things to do") with some "action" (i.e. "mark package FOO for > installation) > 4) apt-get checks if there are any flags set, and if so, acts consequently. > > Would this be an acceptable solution? (but that would imply improving apt-get > itself) no, i don't think it would be acceptable (though of course i'm not an apt maintainer). personally i wouldn't see it as an improvement, only an ugly workaround. also keep in mind that there are a number of package managers and frontends out there, and regardless, dpkg itself would then no longer work in such situations. as an alternative, i'd suggest: - building the modules as part of the upgrade process using dpkg triggers or some other clever mechanism to determine when it needs to be done - storing the modules in a nested subdirectory of /var/lib, like maybe /var/lib/<dkms-or-ma>/modules/<uname -r>/<foo>. - writing an initramfs hook that includes looking for modules from these directories when building the initramfs - making any necessary modifications to module-init-tools so that these directories were included in the search path for modprobe. note that this is non-conflicting with rolling the modules into a .deb package too, but i think is the only clean way to build/install kernel modules if you are already within the package installation process. sean
Attachment:
signature.asc
Description: Digital signature