[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: DKMS - Dynamic Kernel Module Support

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.

: :' :      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?=

Reply to: