David Paleino wrote: > On Fri, 12 Sep 2008 11:12:59 +0000, Tzafrir Cohen wrote: > > >> Furthermore, m-a is part of the package management system, which is a >> good thing. Indeed, as reasoned below >> [...] >> >> Building packages should be the norm. Having many files under /lib that >> cannot be tracked by debsums is not something I like. >> >> [...] >> > The modules are meant to be handled by dkms, not dpkg. If you need a .deb, it > might be a problem, then. > There are a couple reasons against this IMHO:
- Having files *vital* to the system not tracked by dpkg is counter-productive. At the very least it thwarts the most basic and obvious way of integrity protection. It does provide a fantastic opportunity to leave cruft behind when uninstalling, too - Where, for security reasons, the full build is unavailable (i.e. removed from production servers), source-only DKMS would be completely unusable. However, in a farm of identical servers (quite normal nowadays), a sysadmin would only need to have one particular machine equipped with the build system plus full DKMS. Modules would then be distributed to the other servers via a private repository. The second item above brings the same issue again. My vote goes for using an approach similar to module-assistant here, and generate "versioned" modules which can co-exist within a system. Moreover, the generated modules would be installed normally, under /lib/modules/${KVERS} and tracked by dpkg. One idea which comes to mind (without further thinking) is to merge both approaches: dkms could become a "subsystem" of module-assistant in Debian: As presented above, installing kernel-headers and/or booting a kernel for which modules are unavailable would trigger building the necessary modules with DKMS, and module-assistant would be used to generate the policy-conforming .deb. This package would then be installed automatically, so that boot can continue. When the rebuild is triggered by booting with a new kernel, dpkg is not active and can be invoked to *register* the new modules, hence realizing the accountability objective. When triggered by dpkg installing a -headers package .... well, we'll have to devise a solution for this. As said before in this thread, and knowing nary a thing about dpkg's internals, it might just not be possible to do this. However, solving this problem might, as hinted before, provide us with a more elegant solution to other issues. In any case, since updating -headers can never happen without human intervention (save, maybe, for apt-cron), it is not unreasonable to require the admin to manually install the packages immediately after. Moreover, some script might be provided to automate this process: e.g. drop a file in some /etc/dkms/pending.d/<module> file which said script would use in order to install the just-generated modules. AFAICS, the aforementioned solution covers all three use cases: - Updating -headers, wanting to have modules installed immediately (so as not to lengthen the boot period --- think the VoIP case pointed out before). Just run the provided script (à la "update-grub") - Updating -headers in the "master" machine, then being able to replicate just the binary packages to other machines so that they are available upon next boot, without the need for a working build environment in those machines - When the modules don't get installed before reboot, the built packages can be looked for in some predetermined location. If unavailable, the modules could be built and installed on the spot (again, out of any dpkg loop) I may perfectly well be leaving some use case out, but this could be a starting point. My two cents. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]