Re: Bug#491601: madwifi-source fails to build against 2.6.24-etchnhalf.1-486
Kel Modderman <email@example.com> writes:
> Unfortunately, I don't think etch will see another update to fix this
> problem. A backport from sid/testing could be done, the porter would
> need to drop debhelper compat level. However, the delta between madwifi
> upstream in etch and sid/testing is very large. A bacport of madwifi
> 0.9.4 based package could be possible, however the 0.9.4 based package
> has been superceded in sid/testing recently in favour of something far
> more bleeding edge.
> Picking out the exact upstream backports required to fix the antiquated
> madwifi version in etch for 2.6.24 would be tedious, time consuming and
> very error prone. Especially hard for a novice Linux kernel code hacker
> such as myself.
> The same problem exists for ndiswrapper in etch, and probably other
> module-source packages too.
Yup, openafs has essentially exactly the same problem as you describe
above, with the additional twist that it has userspace programs that need
to be updated if the kernel module goes to a much newer version. It came
up a bit earlier without any particularly good conclusion.
My current plan is to let etchnhalf users pull the module source from
backports.org since all the other solutions that I can think of at the
moment look very time-consuming and I just don't have the time to pursue
any of them. But I'd love to hear a better solution.
> Hopefully there is such a plan for Lenny+1/2, and hopefully it doesn't
> mandate the cherry picking of exact API fixes for external modules, but
> rather the backporting of new upstream versions that had seen some time
> in the archive post-stable-release.
Yes. We should probably start planning soon after the release of lenny
for the module update process, similar to how I'm sure the etchnhalf team
started planning for the kernel soon after the release of etch (or
sooner). I too would prefer to have a newer version of the openafs
package from Debian testing backported to lennynhalf rather than trying to
cherry-pick upstream changes, since I have serious doubts about the
stability of a cherry-picked release.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>