4:40 p.m.
Hello,
What are your comments, ideas or opinions about packaging kernel
modules? Fedora has technically banned them AFAIK, but that won't go
well for the proprietary drivers... Should we have both kmod and dkms
available, or maybe something else?
Stewart
5:53 p.m.
On 14.10.2007 18:40, Stewart Adam wrote:
What are your comments, ideas or opinions about packaging kernel
modules? Fedora has technically banned them AFAIK, but that won't go
well for the proprietary drivers... Should we have both kmod and dkms
available, or maybe something else?
Some notes from my side:
* I'm fine with either using both kmods and dkms for all modules or
banning modules for the start completely and leaving them in freshrpms
and livna for now. The latter is *iirc* what thias suggested last time
we talked about it
* "or maybe something else" -- I have some stuff here on my machine that
can dynamically rebuild and install kmod.src.rpms. But well, it's not
ready for primetime yet. Other work (mainly for rpmfusion) kept me away
from it :-/
Cu
knurd
6:17 p.m.
Thorsten Leemhuis wrote:
On 14.10.2007 18:40, Stewart Adam wrote:
> What are your comments, ideas or opinions about packaging kernel
> modules? Fedora has technically banned them AFAIK, but that won't go
> well for the proprietary drivers... Should we have both kmod and dkms
> available, or maybe something else?
Some notes from my side:
* I'm fine with either using both kmods and dkms for all modules or
banning modules for the start completely and leaving them in freshrpms
and livna for now. The latter is *iirc* what thias suggested last time
we talked about it
I'm strongly against leaving kmod's / dkms in the old repo's we want the old
repo's to go away. Not because the old repo's are bad, but for clarity to the
end user.
* "or maybe something else" -- I have some stuff here on my
machine that
can dynamically rebuild and install kmod.src.rpms. But well, it's not
ready for primetime yet. Other work (mainly for rpmfusion) kept me away
from it :-/
Well for both ati and nvidea spec files have been made which build both kmod
and dkms, with them both using the same userspace support, so the user can
choose (or yum will choose the shortest named one if the user doesn't, but foes
install the userspace part).
Regards,
Hans
6:22 p.m.
On Sunday, October 14, 2007 1:53:42 pm Thorsten Leemhuis wrote:
On 14.10.2007 18:40, Stewart Adam wrote:
> What are your comments, ideas or opinions about packaging kernel
> modules? Fedora has technically banned them AFAIK, but that won't go
> well for the proprietary drivers... Should we have both kmod and dkms
> available, or maybe something else?
Some notes from my side:
* I'm fine with either using both kmods and dkms for all modules or
banning modules for the start completely and leaving them in freshrpms
and livna for now. The latter is *iirc* what thias suggested last time
we talked about it
* "or maybe something else" -- I have some stuff here on my machine that
can dynamically rebuild and install kmod.src.rpms. But well, it's not
ready for primetime yet. Other work (mainly for rpmfusion) kept me away
from it :-/
Cu
knurd
I would say DKMS is the better way to go, because it's literally "fire and
forget" - using KMOD would require updating the modules every time the kernel
is updated. Livna's past history in this regard tends to show why this is a
bad approach (it wasn't unusual for me to update the kernel, only to find
that the modules hadn't been updated).
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
6:29 p.m.
On 14.10.2007 20:22, Kelly wrote:
On Sunday, October 14, 2007 1:53:42 pm Thorsten Leemhuis wrote:
> On 14.10.2007 18:40, Stewart Adam wrote:
>> What are your comments, ideas or opinions about packaging kernel
>> modules? Fedora has technically banned them AFAIK, but that won't go
>> well for the proprietary drivers... Should we have both kmod and dkms
>> available, or maybe something else?
> Some notes from my side:
>
> * I'm fine with either using both kmods and dkms for all modules or
> banning modules for the start completely and leaving them in freshrpms
> and livna for now. The latter is *iirc* what thias suggested last time
> we talked about it
>
> * "or maybe something else" -- I have some stuff here on my machine that
> can dynamically rebuild and install kmod.src.rpms. But well, it's not
> ready for primetime yet. Other work (mainly for rpmfusion) kept me away
> from it :-/
I would say DKMS is the better way to go, because it's literally "fire and
forget"
Offloading trouble to users (in case a module does not build for a new
kernel), forcing them to install compilers, having files on harddisk
that are not in the rpmdb, directories and files that stay around after
uninstalling and "we are no gentoo" are IMHO more then good reasons to
not for dkms only. OTOH dkms serves some use cases, that's why I think
having them in addition can't hurt. Users can choose what matches their
use-case best.
- using KMOD would require updating the modules every time the kernel
is updated. Livna's past history in this regard tends to show why this is a
bad approach (it wasn't unusual for me to update the kernel, only to find
that the modules hadn't been updated).
Multiple ten-thousands of users seem to be happy with what livna was
doing (that's the # of download for kmods in total per kernel). Livna in
the past months did updates within 12 hours after the kernel gets
shipped. Often quicker, so it hit users systems often before their
mirror had it...
CU
knurd
6048
days inactive
6048
days old
rpmfusion-developers@lists.rpmfusion.org
4 comments
4 participants
participants (4)
-
Hans de Goede -
Kelly Miller -
Stewart Adam -
Thorsten Leemhuis