[users] DKMS modules ?

[Dag Wieers]

Hi,

Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.

So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

Any objections ?

[Christoph Maser]

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

Chris

[Nicolas Thierry-Mieg]

Post by Christoph Maser

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,
good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

+1
dkms was a hell of a lot better than the old non-tracking kmods that you
had to update at every kernel upgrade, but the elrepo kabi-tracking
kmods are another step forward in terms of ease-of-use.
It should also put an end to the recurrent questions/complaints on the
centos list about the rf dkms nvidia drivers being too old etc...

[Karanbir Singh]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.

So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.

Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

- KB

[Fabian Arrotin]

Post by Karanbir Singh

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?
- KB

I was thinking that Dag was talking about dkms-* packages and not dkms
itself.
I'm aware of the virtualbox case and not from the qlogic one. I'd say
that keeping dkms itself would be a good choice

[Dag Wieers]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads, then
thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with reasonable
testing is the way to go for local and perhaps inherited payloads - there are
a fair few third parties ( in reference with rpmforge as being the second
party ) who carry dkms payloads and can offload to there. VirtualBox being
perhaps the most user visible of the lot, some qlogic drivers being one of
the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and retain
dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

[Karanbir Singh]

Post by Dag Wieers

Post by Karanbir Singh
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

Cool :)

go kmod's!

- KB

[Karanbir Singh]

Post by Dag Wieers

Post by Karanbir Singh
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

Cool :)

go kmod's!

- KB

[Karanbir Singh]

Post by Dag Wieers

Post by Karanbir Singh
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

Cool :)

go kmod's!

- KB

[Karanbir Singh]

Post by Dag Wieers

Post by Karanbir Singh
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

Cool :)

go kmod's!

- KB

[Karanbir Singh]

Post by Dag Wieers

Post by Karanbir Singh
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

Cool :)

go kmod's!

- KB

[Fabian Arrotin]

Post by Karanbir Singh

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?
- KB

I was thinking that Dag was talking about dkms-* packages and not dkms
itself.
I'm aware of the virtualbox case and not from the qlogic one. I'd say
that keeping dkms itself would be a good choice

[Dag Wieers]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads, then
thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with reasonable
testing is the way to go for local and perhaps inherited payloads - there are
a fair few third parties ( in reference with rpmforge as being the second
party ) who carry dkms payloads and can offload to there. VirtualBox being
perhaps the most user visible of the lot, some qlogic drivers being one of
the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and retain
dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

[Fabian Arrotin]

Post by Karanbir Singh

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?
- KB

I was thinking that Dag was talking about dkms-* packages and not dkms
itself.
I'm aware of the virtualbox case and not from the qlogic one. I'd say
that keeping dkms itself would be a good choice

[Dag Wieers]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads, then
thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with reasonable
testing is the way to go for local and perhaps inherited payloads - there are
a fair few third parties ( in reference with rpmforge as being the second
party ) who carry dkms payloads and can offload to there. VirtualBox being
perhaps the most user visible of the lot, some qlogic drivers being one of
the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and retain
dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

[Fabian Arrotin]

Post by Karanbir Singh

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?
- KB

I was thinking that Dag was talking about dkms-* packages and not dkms
itself.
I'm aware of the virtualbox case and not from the qlogic one. I'd say
that keeping dkms itself would be a good choice

[Dag Wieers]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads, then
thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with reasonable
testing is the way to go for local and perhaps inherited payloads - there are
a fair few third parties ( in reference with rpmforge as being the second
party ) who carry dkms payloads and can offload to there. VirtualBox being
perhaps the most user visible of the lot, some qlogic drivers being one of
the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and retain
dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

[Fabian Arrotin]

Post by Karanbir Singh

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?
- KB

I was thinking that Dag was talking about dkms-* packages and not dkms
itself.
I'm aware of the virtualbox case and not from the qlogic one. I'd say
that keeping dkms itself would be a good choice

[Dag Wieers]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads, then
thats fine. I am not personally sure that is the case.
So while I agree and almost always have that kabi tracking with reasonable
testing is the way to go for local and perhaps inherited payloads - there are
a fair few third parties ( in reference with rpmforge as being the second
party ) who carry dkms payloads and can offload to there. VirtualBox being
perhaps the most user visible of the lot, some qlogic drivers being one of
the most obscure.
Is the thinking that drop everything dkms, or just dkms-<ko's> and retain
dkms itself ?

Only the unmaintained dkms modules. The dkms package stays available and
will be updated (when needed).

[Nicolas Thierry-Mieg]

Post by Christoph Maser

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,
good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

+1
dkms was a hell of a lot better than the old non-tracking kmods that you
had to update at every kernel upgrade, but the elrepo kabi-tracking
kmods are another step forward in terms of ease-of-use.
It should also put an end to the recurrent questions/complaints on the
centos list about the rf dkms nvidia drivers being too old etc...

[Karanbir Singh]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.

So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.

Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

- KB

[Nicolas Thierry-Mieg]

Post by Christoph Maser

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,
good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

+1
dkms was a hell of a lot better than the old non-tracking kmods that you
had to update at every kernel upgrade, but the elrepo kabi-tracking
kmods are another step forward in terms of ease-of-use.
It should also put an end to the recurrent questions/complaints on the
centos list about the rf dkms nvidia drivers being too old etc...

[Karanbir Singh]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.

So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.

Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

- KB

[Nicolas Thierry-Mieg]

Post by Christoph Maser

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,
good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

+1
dkms was a hell of a lot better than the old non-tracking kmods that you
had to update at every kernel upgrade, but the elrepo kabi-tracking
kmods are another step forward in terms of ease-of-use.
It should also put an end to the recurrent questions/complaints on the
centos list about the rf dkms nvidia drivers being too old etc...

[Karanbir Singh]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.

So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.

Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

- KB

[Nicolas Thierry-Mieg]

Post by Christoph Maser

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,
good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

+1
dkms was a hell of a lot better than the old non-tracking kmods that you
had to update at every kernel upgrade, but the elrepo kabi-tracking
kmods are another step forward in terms of ease-of-use.
It should also put an end to the recurrent questions/complaints on the
centos list about the rf dkms nvidia drivers being too old etc...

[Karanbir Singh]

Post by Christoph Maser

Post by Dag Wieers
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

If the assumption is the dkms world is only populated by local payloads,
then thats fine. I am not personally sure that is the case.

So while I agree and almost always have that kabi tracking with
reasonable testing is the way to go for local and perhaps inherited
payloads - there are a fair few third parties ( in reference with
rpmforge as being the second party ) who carry dkms payloads and can
offload to there. VirtualBox being perhaps the most user visible of the
lot, some qlogic drivers being one of the most obscure.

Is the thinking that drop everything dkms, or just dkms-<ko's> and
retain dkms itself ?

- KB

[Dag Wieers]

Hi,

Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.

So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

Any objections ?

[Christoph Maser]

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

Chris

[Dag Wieers]

Hi,

Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.

So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

Any objections ?

[Christoph Maser]

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

Chris

[Dag Wieers]

Hi,

Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.

So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

Any objections ?

[Christoph Maser]

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

Chris

[Dag Wieers]

Hi,

Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.

So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).

Any objections ?

[Christoph Maser]

Post by Dag Wieers
Hi,
Let's open the discussion one last time regarding DKMS modules. Our
current offering is outdated and not something I want to promote. While I
do think dkms modules offer benefits in certain situations, I have to say
that kmods (by virtue of ELRepo) is what I believe in most.
So unless someone stands up and wants to maintain the existing dkms
packages, I think we should get rid of the current dkms packages (at least
for RHEL5+).
Any objections ?

Hi Dag,

good idea. ELRepo is going a really good job and getting rid of
unmaintaned packages is always a good idea.

Chris