Le samedi 13 septembre 2008 à 00:44 +0200, José Luis Tallón a écrit : > - 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. Dpkg is not tripwire. If you think you can rely on dpkg for checking data integrity, you are fooling yourself. > It does provide a fantastic > opportunity to leave cruft behind when uninstalling, too These are things that we already know how to deal with. > - 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. Having a way to automatically install modules doesn’t prevent from building .debs containing them, as it was already explained multiple times. Furthermore, the target of DKMS is not server-grade material, for which use of out-of-tree modules is exceptional; it is for desktops and laptops with non-free graphics and wifi. In most cases you don’t care of having distributable packages. > 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. Elegant? You are advising to intertwin the boot process and the package manager, and you invoke elegance? Please, stop this bullshit. Unless dpkg’s architecture is revamped to allow such things (and I’m not sure it is wise to do so), you are just blowing hot air. We probably have all we need today to get things like DKMS to work, and you are just arguing for delaying such critical desktop features for no good reason. > 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. If we aren’t able to bring an improvement, let’s just stick with module-assistant, then. The point of dkms is that we might finally be able to provide a way to simply “install a driver” and be done with it, having something to automatically care of all upgrades. Please don’t use this as a pretext to introduce changes we don’t need to the most fundamental piece of software in Debian. Thanks, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=