So, I have a little proposal for the Fedora kernel SRPM...
TL;DR -- I want to create a kernel-backports package that includes the output of building compat-wireless against the corresponding kernel. A version of this package will automatically be built for every kernel RPM built.
Why?
Hardware enablement is an endless treadmill. As Fedora has matured, the delta between current Fedora kernels and current upstream kernels has tended to widen (at least for older releases e.g. F14). This can cause problems both for users needing cutting-edge hardware support and for developers trying to diagnose problems in Fedora kernels that may have already been fixed upstream.
Creating a seperate package allows both of the above situations to be addressed while allowing "normal" users to use the base kernel without unnecessary risk of destabilization. Integrating the build of that package with the kernel build ensures that every new kernel automatically has a kernel-backports package built without need of human intervention or creative scripting.
How does this proposal look?
I have a scratch F14 kernel build available here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3404605
You will also need an updated module-init-tools package:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3404725
When you install the kernel-backports package, modinfo for an affected driver (e.g. iwlagn) will show that the driver chosen by depmod will change. Removing kernel-backports will point you back to the version from the base kernel.
What is in the kernel-backports package?
At present, a stable release of the compat-wireless project would be included in the kernel-backports package:
http://www.linuxwireless.org/en/users/Download
The compat-wireless project contains backports of sources from current upstream kernels. These are not out-of-tree drivers in the traditional sense. These drivers are in-tree -- just a later version of the tree. As such, the compat-wireless sources follow the same license as the upstream Linux kernel (i.e. GPLv2).
The compat-* project is expected/intended to expand to include wired networking drivers and more in the future. As that happens, those new compat-* drivers will be included in the kernel-backports package as well.
Isn't this just a big kmod package?
No, or at least not exactly. Existing kmod package standards require a separate kmod build for every kernel build. Most (or all?) of them require complex versioning to distinquish between versions of the kmod package and versions of the target kernel. They are a nightmare to maintain. Worse, they require multiple kmod packages for multiple drivers, multiplying the maintenance burden.
This proposal minimizes the maintenance required while maximizing the coverage of driver upates. A single compat-wireless package update will suffice to update a full suite of drivers all at once.
Isn't this too "bleeding edge" for non-rawhide Fedora?
Perhaps so, at least for many people. That is the advantage of having a separate kernel-backports package. Those that don't want to use the cutting-edge hardware support will simply not install the package. Those who want or need that support will have it easily available.
Why not just use Rawhide?
Rawhide might have even more "bleeding" edge hardware support than the kernel-backports package would get. Plus, Rawhide kernels will have less mature core kernel changes as well. Keeping a stable release kernel with a kernel-backports package offers an intermediate step towards cutting-edge hardware support while maintaining a stable core kernel.
Who will maintain it?
For now, I will. When I am old and gone, my successor will only have to update the compat-wireless bits once per upstream kernel release and perhaps add a few Fedora-specific compat-wireless patches as things are backported to the Fedora base kernel that conflict with the compat layer in compat-wireless.
Can we turn it off easily?
Yes. The spec file changes are all bracketed by a "with_backports" symbol already. In fact, with_backports will have to be turned-off in Rawhide and in any other Fedora releases where the kernel version is the same or newer than the latest compat-wireless stable release.
What do the changes look like?
I'll paste the kernel.spec file changes for F14 below. I'll attach the required module-init-tools.spec file patch to this email for reference as well.
Conclusion
So, there is my proposal. What are the objections?
Once any major objections are addressed, I'll pursue any required Fedora project management items required (e.g. a Feature page).
John
---
diff --git a/kernel.spec b/kernel.spec index cc12bce..b96c348 100644 --- a/kernel.spec +++ b/kernel.spec @@ -25,6 +25,7 @@ Summary: The Linux kernel # # % define buildid .local ################################################################### +%define buildid .1.compat
# The buildid can also be specified on the rpmbuild command line # by adding --define="buildid .whatever". If both the specfile and @@ -147,6 +148,10 @@ Summary: The Linux kernel # should we do C=1 builds with sparse %define with_sparse %{?_with_sparse: 1} %{?!_with_sparse: 0}
+# Include driver backports (e.g. compat-wireless) in the kernel build. +# This builds a separate kernel-backports package. +%define with_backports %{?_with_backports: 1} %{?!_with_backports: 0} + # Set debugbuildsenabled to 1 for production (build separate debug kernels) # and 0 for rawhide (all kernels are debug kernels). # See also 'make debug' and 'make release'. @@ -531,6 +536,9 @@ BuildRequires: rpm-build >= 4.4.2.1-4 %endif
Source0: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-%{kversion}.tar.bz2 +%if %{with_backports} +Source1: compat-wireless-3.0-2.tar.bz2 +%endif
Source11: genkey Source14: find-provides @@ -864,6 +872,10 @@ Patch14050: x86-PCI-don-t-use-native-Broadcom-CNB20LE-driver-whe.patch # RHBZ #648571 Patch14051: modules-Fix-module_bug_list-list-corruption-race.patch
+%if %{with_backports} +Patch20000: compat-wireless-vzalloc.patch +%endif + %endif
BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root @@ -1042,6 +1054,37 @@ It should only be installed when trying to gather additional information on kernel bugs, as some of these options impact performance noticably.
+%if %{with_backports} + +# +# This macro creates a kernel-backports-<subpackage>. +# %%kernel_variant_backports_package <condition> <subpackage> +# +%define kernel_variant_backports_package() \ +%if %{1}\ +%package %{?2:%{2}-}backports\ +Summary: Drivers backported from later versions of the Linux kernel\ +Group: System Environment/Kernel\ +License: GPLv2\ +Requires: kernel = %{rpmversion}-%{pkg_release}\ +Requires(post): module-init-tools >= 3.11.1-6.1.compat\ +%description %{?2:%{2}-}backports\ +This package provies pre-compiled drivers backported from later versions\ +of the Linux kernel. This package contains drivers from the upstream\ +Linux kernel exclusively. Out-of-tree drivers are not provided.\ +This version matches the kernel%{?2:-%{2}} package.\ +%{nil}\ +%endif + +%kernel_variant_backports_package %{with_up} +%kernel_variant_backports_package %{with_smp} smp +%kernel_variant_backports_package %{with_debug} debug +%kernel_variant_backports_package %{with_pae} PAE +%kernel_variant_backports_package %{with_pae_debug} PAEdebug + +%endif + + %prep # do a few sanity-checks for --with *only builds %if %{with_baseonly} @@ -1670,6 +1713,16 @@ find . ( -name "*.orig" -o -name "*~" ) -exec rm -f {} ; >/dev/null
cd ..
+%if %{with_backports} + +# Extract the compat-wireless bits +%setup -q -n kernel-%{kversion}%{?dist} -T -D -a 1 + +cd compat-wireless-3.0-2 +%patch20000 -p1 + +%endif + ### ### build ### @@ -1787,6 +1840,9 @@ BuildKernel() { # dirs for additional modules per module-init-tools, kbuild/modules.txt mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/extra mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/updates +%if %{with_backports} + mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer/backports +%endif # first copy everything cp --parents `find -type f -name "Makefile*" -o -name "Kconfig*"` $RPM_BUILD_ROOT/lib/modules/$KernelVer/build cp Module.symvers $RPM_BUILD_ROOT/lib/modules/$KernelVer/build @@ -1886,6 +1942,23 @@ BuildKernel() { mkdir -p $RPM_BUILD_ROOT/usr/src/kernels mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir ln -sf ../../..$DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build + +%if %{with_backports} + + cd ../compat-wireless-3.0-2/ + make clean + + make KLIB_BUILD=../linux-%{kversion}.%{_target_cpu} \ + KMODPATH_ARG="INSTALL_MOD_PATH=$RPM_BUILD_ROOT" \ + KMODDIR="backports" install-modules + + # mark modules executable so that strip-to-file can strip them + find $RPM_BUILD_ROOT/lib/modules/$KernelVer/backports -name "*.ko" \ + -type f | xargs --no-run-if-empty chmod u+x + + cd - + +%endif }
### @@ -2103,6 +2176,54 @@ fi}\ %kernel_variant_post -v PAEdebug -r (kernel|kernel-smp) %kernel_variant_preun PAEdebug
+%if %{with_backports} + +# +# This macro defines a depmod operation for install/remove of backports. +# %%kernel_variant_backports_depmod [-v <subpackage>] +# +%define kernel_variant_backports_depmod(v:) \ +%{expand:\ +/sbin/depmod -ae -F /boot/System.map-%{KVERREL}%{?-v:.%{-v*}} || exit $?\ +}\ +%{nil} + +# +# This macro defines a %%post script for a kernel backports package. +# %%kernel_variant_backports_post <condition> <subpackage> +# +%define kernel_variant_backports_post() \ +%if %{1}\ +%{expand:%%post %{?2:%{2}-}backports}\ +%{expand:%%kernel_variant_backports_depmod %{?2:-v %{2}}}\ +%endif\ +%{nil} + +# +# This macro defines a %%postun script for a kernel backports package. +# %%kernel_variant_backports_postun <condition> <subpackage> +# +%define kernel_variant_backports_postun() \ +%if %{1}\ +%{expand:%%postun %{?2:%{2}-}backports}\ +%{expand:%%kernel_variant_backports_depmod %{?2:-v %{2}}}\ +%endif\ +%{nil} + +%kernel_variant_backports_post %{with_up} +%kernel_variant_backports_post %{with_smp} smp +%kernel_variant_backports_post %{with_debug} debug +%kernel_variant_backports_post %{with_pae} PAE +%kernel_variant_backports_post %{with_pae_debug} PAEdebug + +%kernel_variant_backports_postun %{with_up} +%kernel_variant_backports_postun %{with_smp} smp +%kernel_variant_backports_postun %{with_debug} debug +%kernel_variant_backports_postun %{with_pae} PAE +%kernel_variant_backports_postun %{with_pae_debug} PAEdebug + +%endif + if [ -x /sbin/ldconfig ] then /sbin/ldconfig -X || exit $? @@ -2209,10 +2330,39 @@ fi %kernel_variant_files %{with_pae} PAE %kernel_variant_files %{with_pae_debug} PAEdebug
+ +%if %{with_backports} + +# +# This macro defines the %%files sections for a kernel-backports +# package. +# %%kernel_variant_backports_files <condition> <subpackage> +# +%define kernel_variant_backports_files() \ +%if %{1}\ +%{expand:%%files %{?2:%{2}-}backports}\ +%defattr(-,root,root)\ +/lib/modules/%{KVERREL}%{?2:.%{2}}/backports\ +%endif\ +%{nil} + +%kernel_variant_backports_files %{with_up} +%kernel_variant_backports_files %{with_smp} smp +%kernel_variant_backports_files %{with_debug} debug +%kernel_variant_backports_files %{with_pae} PAE +%kernel_variant_backports_files %{with_pae_debug} PAEdebug + +%endif + + # plz don't put in a version string unless you're going to tag # and build.
%changelog +* Tue Oct 4 2011 John W. Linville linville@redhat.com +- Add infrastructure for kernel-backports package +- Include compat-wireless project in package above + * Mon Sep 12 2011 Josh Boyer jwboyer@redhat.com - Backport 5336377d to fix RHBZ #648571
On Thu, Oct 06, 2011 at 12:00:42PM -0400, John W. Linville wrote:
Hardware enablement is an endless treadmill. As Fedora has matured, the delta between current Fedora kernels and current upstream kernels has tended to widen (at least for older releases e.g. F14).
Right, but we're moving away from that, and trying to get back to the older model where we ship at least the current-1 release. (But not for 14, because it's such a quantum leap).
Are you proposing this for _just_ 14 ? In which case, I'd be fine with that, because we're not rebasing it.
For 15 onwards, I don't think this is worth it.
Dave
On Thu, Oct 06, 2011 at 12:08:27PM -0400, Dave Jones wrote:
On Thu, Oct 06, 2011 at 12:00:42PM -0400, John W. Linville wrote:
Hardware enablement is an endless treadmill. As Fedora has matured, the delta between current Fedora kernels and current upstream kernels has tended to widen (at least for older releases e.g. F14).
Right, but we're moving away from that, and trying to get back to the older model where we ship at least the current-1 release. (But not for 14, because it's such a quantum leap).
Are you proposing this for _just_ 14 ? In which case, I'd be fine with that, because we're not rebasing it.
For 15 onwards, I don't think this is worth it.
Until 3.1 is released, F14 is the only release that can use it anyway. That said, I would like to use it there if nothing else.
As for F15 and beyond, current-1 can still be enough delta to cause problems. Also, obstacles against updating kernel releases can be unpredictable.
Maybe we could have it in the .spec file for all the releases, but have it turned-off by default? Then at least it is there if we need it.
Using compat-wireless is a good way to make even more up-to-date hardware support available in Fedora at nearly no cost to us. I would really like to see us take advantage of it.
John
On Thu, Oct 06, 2011 at 12:21:11PM -0400, John W. Linville wrote:
Are you proposing this for _just_ 14 ? In which case, I'd be fine with that, because we're not rebasing it.
For 15 onwards, I don't think this is worth it.
Until 3.1 is released, F14 is the only release that can use it anyway. That said, I would like to use it there if nothing else.
As for F15 and beyond, current-1 can still be enough delta to cause problems. Also, obstacles against updating kernel releases can be unpredictable.
Maybe we could have it in the .spec file for all the releases, but have it turned-off by default? Then at least it is there if we need it.
Using compat-wireless is a good way to make even more up-to-date hardware support available in Fedora at nearly no cost to us. I would really like to see us take advantage of it.
Another possibility is just using git-wireless in f15/f16 and beyond. Which we've done before..
I'm thinking along the lines of having stuff just work by default rather than having users file bugs when something breaks, and then having to tell them 'oh, install compat-wireless'.
Dave
On Thu, Oct 06, 2011 at 12:34:19PM -0400, Dave Jones wrote:
On Thu, Oct 06, 2011 at 12:21:11PM -0400, John W. Linville wrote:
Are you proposing this for _just_ 14 ? In which case, I'd be fine with that, because we're not rebasing it.
For 15 onwards, I don't think this is worth it.
Until 3.1 is released, F14 is the only release that can use it anyway. That said, I would like to use it there if nothing else.
As for F15 and beyond, current-1 can still be enough delta to cause problems. Also, obstacles against updating kernel releases can be unpredictable.
Maybe we could have it in the .spec file for all the releases, but have it turned-off by default? Then at least it is there if we need it.
Using compat-wireless is a good way to make even more up-to-date hardware support available in Fedora at nearly no cost to us. I would really like to see us take advantage of it.
Another possibility is just using git-wireless in f15/f16 and beyond. Which we've done before..
I'm thinking along the lines of having stuff just work by default rather than having users file bugs when something breaks, and then having to tell them 'oh, install compat-wireless'.
You mean just have it in the base kernel package? I would be happy with that. The idea for a seperate package was mostly to give an escape hatch for those that didn't want the later drivers for whatever reason. But if we stick to the compat-wireless releases based on stable kernels, I don't think there is a great stability concern with just using them for everyone.
Removing the bits of the patch that generate separate packages is nearly trivial. I'll be happy to do that if that is generally preferred. :-)
John
On Thu, Oct 06, 2011 at 12:40:00PM -0400, John W. Linville wrote:
I'm thinking along the lines of having stuff just work by default rather than having users file bugs when something breaks, and then having to tell them 'oh, install compat-wireless'.
You mean just have it in the base kernel package? I would be happy with that.
yeah.
The idea for a seperate package was mostly to give an escape hatch for those that didn't want the later drivers for whatever reason.
I'd have thought the opposite would be desirable. People usually *want* new drivers.
But if we stick to the compat-wireless releases based on stable kernels, I don't think there is a great stability concern with just using them for everyone.
Removing the bits of the patch that generate separate packages is nearly trivial. I'll be happy to do that if that is generally preferred. :-)
We've carried some of the other git trees in the past, and as long as someone is maintaining them (which I'm sure you will), I don't see it being a big deal.
Dave
On Thu, Oct 06, 2011 at 12:50:44PM -0400, Dave Jones wrote:
On Thu, Oct 06, 2011 at 12:40:00PM -0400, John W. Linville wrote:
I'm thinking along the lines of having stuff just work by default rather than having users file bugs when something breaks, and then having to tell them 'oh, install compat-wireless'.
You mean just have it in the base kernel package? I would be happy with that.
yeah.
The idea for a seperate package was mostly to give an escape hatch for those that didn't want the later drivers for whatever reason.
I'd have thought the opposite would be desirable. People usually *want* new drivers.
OK, so the truth is that I just wanted to learn how to produce those extra RPM from the kernel.spec file -- is that so wrong??? :-)
But if we stick to the compat-wireless releases based on stable kernels, I don't think there is a great stability concern with just using them for everyone.
Removing the bits of the patch that generate separate packages is nearly trivial. I'll be happy to do that if that is generally preferred. :-)
We've carried some of the other git trees in the past, and as long as someone is maintaining them (which I'm sure you will), I don't see it being a big deal.
You had me at "hello"...
Alright then, I'll plan on proceeding with this "soon" (since I'm taking a long weekend). What about F14? Should I leave it with the separate package stuff? Go ahead and integrate the compat-wireless bits into the base kernel package? Or just leave it alone?
Thanks,
John
On Thu, Oct 06, 2011 at 01:08:02PM -0400, John W. Linville wrote:
Alright then, I'll plan on proceeding with this "soon" (since I'm taking a long weekend). What about F14? Should I leave it with the separate package stuff? Go ahead and integrate the compat-wireless bits into the base kernel package? Or just leave it alone?
"What to do about f14" is something we've been asking a lot lately. We've already decided we're not rebasing, and we're not going to be backporting every fix, so the answer for the most part has been "sorry, try f15/f16", which is a pretty crap response from the users point of view, but hopefully we'll not fall back into this mistake of sitting on a year old codebase again.
The -longterm releases are a great idea in theory, but when you think about what they're actually doing (replicating the workload of an enterprise kernel, but with a handful people at most), it's pretty obvious that you can't rely on them to fix everything.
So to answer your question: if you want to do compat-wireless in f14, fine. If you want to backport wireless.git to it, fine. At the end of the day, you get the bugs that result from drivers/net/wireless/ so whatever that code ends up being, it's your doing.. :-)
Dave
On 10/06/2011 01:08 PM, John W. Linville wrote:
Alright then, I'll plan on proceeding with this "soon" (since I'm taking a long weekend). What about F14? Should I leave it with the separate package stuff? Go ahead and integrate the compat-wireless bits into the base kernel package? Or just leave it alone?
FWIW, Fedora 14 doesn't have a lot of life left (it will be EOL in December). I'd really prefer we left it alone.
~tom
== Fedora Project
On Thu, Oct 06, 2011 at 12:50:44PM -0400, Dave Jones wrote:
On Thu, Oct 06, 2011 at 12:40:00PM -0400, John W. Linville wrote:
I'm thinking along the lines of having stuff just work by default rather than having users file bugs when something breaks, and then having to tell them 'oh, install compat-wireless'.
You mean just have it in the base kernel package? I would be happy with that.
yeah.
So what happened here? We seemed to have agreement that compat-wireless didn't make sense, and that we'd just carry git-wireless, but I see you just committed compat-wireless to f16/master.
confused.
(also, having it be a tarball is a pain wrt review)
Dave
On Wed, Nov 16, 2011 at 04:19:16PM -0500, Dave Jones wrote:
On Thu, Oct 06, 2011 at 12:50:44PM -0400, Dave Jones wrote:
On Thu, Oct 06, 2011 at 12:40:00PM -0400, John W. Linville wrote:
I'm thinking along the lines of having stuff just work by default rather than having users file bugs when something breaks, and then having to tell them 'oh, install compat-wireless'.
You mean just have it in the base kernel package? I would be happy with that.
yeah.
So what happened here? We seemed to have agreement that compat-wireless didn't make sense, and that we'd just carry git-wireless, but I see you just committed compat-wireless to f16/master.
confused.
Hmmm...I guess there was some misunderstanding between us. I reckon that I didn't catch that you were making a distinction between compat-wireless and my tree that it pulls from. I thought the objection was to building a separate package from the kernel spec.
FWIW, using the compat-wireless version is a lot less work, since all the backporting bits should be done already. And it takes advantage of the backporting skills of the members of that project, rather than relying solely on me. I think it is a better way to proceed, and one I can actually commit to doing.
(also, having it be a tarball is a pain wrt review)
True, but I'm not sure that a giant patch w/ all the wireless-next bits in it would be any easier on the eyes...?
What I have there now is only a build option. I wanted a little time to make sure it is building correctly and whatnot before I sent everyone down that path. I was planning to turn it on for rawhide before too long, and undecided about when I might do that with F16.
Do you have any suggestions? I don't really see compat-wireless as any big danger, and certainly not any bigger danger than a patch from wireless-next.
I would still be open to building a separate backports package instead, if I misunderstood that objection. That is what the brown distro does, FWIW.
So, how to proceed?
John
On Wed, Nov 16, 2011 at 04:48:07PM -0500, John W. Linville wrote:
Hmmm...I guess there was some misunderstanding between us. I reckon that I didn't catch that you were making a distinction between compat-wireless and my tree that it pulls from. I thought the objection was to building a separate package from the kernel spec.
Earlier in this thread I mentioned wanting to avoid this situation: <user> my wireless is broken. *files bug* <us> install compat-wireless! <user> ok, it worked!
Why don't we just make this code the default, and have it just work.
FWIW, using the compat-wireless version is a lot less work, since all the backporting bits should be done already. And it takes advantage of the backporting skills of the members of that project, rather than relying solely on me. I think it is a better way to proceed, and one I can actually commit to doing.
How I see this making most sense :
f15/f16: what you have in compat-wireless, but apply it as default so we ship *those drivers* rather than what was in 3.1
master: git-wireless.next
(also, having it be a tarball is a pain wrt review)
True, but I'm not sure that a giant patch w/ all the wireless-next bits in it would be any easier on the eyes...?
If there's a one-liner that needs fixing up, it means recreating and reuploading a new tarball.
When these changes happen in tarballs, it's entirely opaque when it goes to the commits list. We have no idea what changed.
Dave
On Wed, Nov 16, 2011 at 05:22:16PM -0500, Dave Jones wrote:
On Wed, Nov 16, 2011 at 04:48:07PM -0500, John W. Linville wrote:
Hmmm...I guess there was some misunderstanding between us. I reckon that I didn't catch that you were making a distinction between compat-wireless and my tree that it pulls from. I thought the objection was to building a separate package from the kernel spec.
Earlier in this thread I mentioned wanting to avoid this situation: <user> my wireless is broken. *files bug* <us> install compat-wireless! <user> ok, it worked!
Why don't we just make this code the default, and have it just work.
I want to do just that. I just wanted to make sure I had the bases covered before it went live. :-)
FWIW, using the compat-wireless version is a lot less work, since all the backporting bits should be done already. And it takes advantage of the backporting skills of the members of that project, rather than relying solely on me. I think it is a better way to proceed, and one I can actually commit to doing.
How I see this making most sense :
f15/f16: what you have in compat-wireless, but apply it as default so we ship *those drivers* rather than what was in 3.1
master: git-wireless.next
The code is the same (minus any required backporting) whether it comes from compat-wireless or as a big patch from wireless-next. When it goes live, I can modify the configs to not build the drivers from the base kernel, but only build the ones from the wireless tree instead.
(also, having it be a tarball is a pain wrt review)
True, but I'm not sure that a giant patch w/ all the wireless-next bits in it would be any easier on the eyes...?
If there's a one-liner that needs fixing up, it means recreating and reuploading a new tarball.
When these changes happen in tarballs, it's entirely opaque when it goes to the commits list. We have no idea what changed.
Ah, I see your objection -- that would suck. But I wouldn't do it that way.
In fact, with my original efforts I faced exactly this problem. Fedora had backported vzalloc, and the compat-wireless code had it too. I handled that in the %prep section, the same as how the base kernel is patched (i.e. a %setup for the tarball and a %patch or ApplyPatch for each patch).
So, any fixes would still be reviewable patches. The tarball would only change occasionally. Reviewing the tarball changes would suck, but probably not much worse than reviewing an update of a giant patch from wireless-next.
Does that improve the perspective? :-)
John
Hey John,
I looked at the module-init-tools patch. It's fine to incorporate if this is the chosen plan (to do the backports package). In that case, either you or I (or anyone else) is free to build the updated m-i-t.
Jon.
On Thu, Oct 06, 2011 at 12:19:35PM -0400, Jon Masters wrote:
Hey John,
I looked at the module-init-tools patch. It's fine to incorporate if this is the chosen plan (to do the backports package). In that case, either you or I (or anyone else) is free to build the updated m-i-t.
Jon.
Thanks for the ACK. It isn't too intrusive, but it's good to know that you don't object! :-)
John
Hi!
The discussion moved into a different direction, but nevertheless a few quick comments:
On 06.10.2011 18:00, John W. Linville wrote:
[...] Isn't this just a big kmod package?
No, or at least not exactly. Existing kmod package standards require a separate kmod build for every kernel build. Most (or all?) of them require complex versioning to distinquish between versions of the kmod package and versions of the target kernel. They are a nightmare to maintain.
That's a bit misleading from my point of view, but whatever, likely not worth arguing over the details.
Worse, they require multiple kmod packages for multiple drivers, multiplying the maintenance burden.
See kmod-staging in RPM Fusion for an example of a kmod package (kmod2 to be precise) that contains contains multiple drivers.
diff --git a/depmod-dist.conf b/depmod-dist.conf index 8513288..0585676 100644 --- a/depmod-dist.conf +++ b/depmod-dist.conf @@ -3,4 +3,4 @@ #
# override default search ordering for kmod packaging -search updates extra built-in weak-updates +search updates extra backports built-in weak-updates
And what exactly would be the difference between "updates" and "backports"? Might be wise to at least mention it with a sentence or two in the docs if there is actually one. Is there is: Is it relevant for users or just creating confusion?
Cu knurd
On Thu, Oct 06, 2011 at 09:35:19PM +0200, Thorsten Leemhuis wrote: [...]
diff --git a/depmod-dist.conf b/depmod-dist.conf index 8513288..0585676 100644 --- a/depmod-dist.conf +++ b/depmod-dist.conf @@ -3,4 +3,4 @@ #
# override default search ordering for kmod packaging -search updates extra built-in weak-updates +search updates extra backports built-in weak-updates
And what exactly would be the difference between "updates" and "backports"? Might be wise to at least mention it with a sentence or two in the docs if there is actually one. Is there is: Is it relevant for users or just creating confusion?
The term 'backports' was chosen specifically not to interfere with drivers that may come from out-of-tree drivers and and get installed in 'updates.' The point was to avoid confusion as people might wonder why the out-of-tree driver they download and install broke something that was installed from a Fedora package.
Based on Dave and John's continued conversation this might not be necessary as the default may be to use the drivers from the compat tree rather than having them as an extra package.
On Thu, Oct 06, 2011 at 03:55:41PM -0400, Andy Gospodarek wrote:
On Thu, Oct 06, 2011 at 09:35:19PM +0200, Thorsten Leemhuis wrote: [...]
diff --git a/depmod-dist.conf b/depmod-dist.conf index 8513288..0585676 100644 --- a/depmod-dist.conf +++ b/depmod-dist.conf @@ -3,4 +3,4 @@ #
# override default search ordering for kmod packaging -search updates extra built-in weak-updates +search updates extra backports built-in weak-updates
And what exactly would be the difference between "updates" and "backports"? Might be wise to at least mention it with a sentence or two in the docs if there is actually one. Is there is: Is it relevant for users or just creating confusion?
The term 'backports' was chosen specifically not to interfere with drivers that may come from out-of-tree drivers and and get installed in 'updates.' The point was to avoid confusion as people might wonder why the out-of-tree driver they download and install broke something that was installed from a Fedora package.
Based on Dave and John's continued conversation this might not be necessary as the default may be to use the drivers from the compat tree rather than having them as an extra package.
Well, they still need to be installed somewhere. Putting them somewhere other than their own directory (whatever the name) would require more hacking into the compat-wireless package than I intended to do.
The reason for naming putting it somewhere other than updates (packaged external modules) or extras (locally-built external modules) was to indicate that these modules were something other than the other categories. That still seems reasonable to me.
John
On Thu, 2011-10-06 at 16:01 -0400, John W. Linville wrote:
On Thu, Oct 06, 2011 at 03:55:41PM -0400, Andy Gospodarek wrote:
The reason for naming putting it somewhere other than updates (packaged external modules) or extras (locally-built external modules) was to indicate that these modules were something other than the other categories. That still seems reasonable to me.
I like that. If you're going to ship alternative much newer options, don't put them in "updates" (intended for the local admin), and we have generally used "extra" for packaged drivers. I favor the "backports" directory. New directories are cheap, and searching them is just a trivial config file entry...then users can always get a choice about using a backport. In fact, they can be given a drop-in config file that will change the load order on a per-module basis if they need to replace the standard driver with the compat-wireless option.
Jon.
kernel@lists.fedoraproject.org
-
Andy Gospodarek -
Dave Jones -
John W. Linville -
Jon Masters -
Thorsten Leemhuis -
Tom Callaway