On Wed, Jul 03, 2013 at 03:14:02AM +0000, "Jóhann B. Guðmundsson" wrote:
On 07/03/2013 12:50 AM, Josh Boyer wrote:
>On Tue, Jul 02, 2013 at 09:26:38PM +0000, "Jóhann B. Guðmundsson" wrote:
>>This indicates that we should not be shipping dkms et all so does
>>anyone know anything about the current status on this in the working
>>group?
>DKMS is a framework for rebuilding modules when a new kernel is
>installed. It is primarily targeted at enterprise distributions. If
>someone wants to package and maintain it for Fedora, then I guess that's
>a thing they can do.
I would have thought the kernel community frowned making it
available for end user system.
Oh, I'm sure none of us actually like it in terms of Fedora. But we
can't prevent people from doing every little thing that we don't like
and the kernel taints as out-of-tree if someone loads a module with
dkms.
>>What the way forward is supposed to be?
>Fedora's approach is to get drivers upstream and they'll naturally get
>picked up when we rebase. We don't provide or ship any pre-built
>out-of-tree modules, nor do we support dkms, kmods, or any of the other
>module building frameworks from a kernel perspective. Those are
>supported by the additional persons or repositories that provide them.
Interesting it comes logically to me that we should have aligned
ourselves with opensuse and the working group stance and only make
it available as an build service to provide developer build of
backported modules, or modules that are on their way into mainline
for testing purposes only you know assist those that are willing to
go through steps necessary to making it into mainline ( while doing
the opposite for those that dont as in making it harder since they
would have to carry dkms themselves those usually have questionable
license anyway )
Fedora isn't really a company like Novell or IBM. I have no idea if the
work group reached out to Red Hat at all, but that doesn't matter much
either in regards to Fedora.
We did carry, as part of the kernel package itself, the precursor to the
driver-backports project in the 3.6 timeframe. John Linville used the
compat-wireless tarballs, which are basically backports of the latest
upstream wireless bits and that's what we shipped for wireless drivers
for quite a while. It wasn't the greatest success from a distribution
standpoint. Lots of bugs were hit, and explaining to upstream people
that things were backported was both confusing and frustrating.
In anycase FESCO did not even bother looking into the unit [1]
before allowing dkms to be enabled by default ( that unit will never
work in it's current shape and obviously was not even tested before
being asked to be enabled by default ) so I would not act surprised
when dkms bugs or 3rd party modules don't build correctly get
accidental misfiled against the kernel.
We're used to that. Honestly, I don't believe DKMS is used widely
enough to even worry about it. I can't recall the last time I saw a bug
report about a failing module or module build that involved anything
other than rpmfusion kmods and/or virtual box.
josh