Re: RFC: DKMS - Dynamic Kernel Module Support
On Sat, Sep 13, 2008 at 01:54:43AM +0200, Josselin Mouette wrote:
> 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.
Many of those modules distributed by dkms are ones that the user is also
likely to try installing on his own from source. debsums helps answering
the question: "oh here's a little module, I wonder where it came from?"
Do not assume everybody maintaining the system know of dkms (or of m-a
or such). Knowledge of debsums or equivalent should be assumed from
anybody maintaining a Debian system.
>
> > 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.
Dell developed dkms for Linux servers it ships. Many servers ship with
disk controllers, network controllers and such that are not yet
supported in the kernel of current RHEL or Debian Stable.
In a perfect world all the code would reach mainline kernel soon enough
and we wouldn't need to maintain packages like lirc and zd1211 on our
own.
In the real world, there is also some free software whose maintainers
refuse to include it in the mainline kernel for technical reasons.
And as I mentioned before, the problem with those generated debs is that
you can not install two of them on your system if you have two different
kernel variants.
--
Tzafrir Cohen | tzafrir@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tzafrir@cohens.org.il | | best
ICQ# 16849754 | | friend
Reply to: