On Sun, 2007-11-04 at 22:59 -0500, Marc Sherman wrote: > dann frazier wrote: > > > > For modules, my immediate thought is to find the first option below > > that works: > > > > 1) Does the existing version work with 2.6.23 as-is? > > 2) Can support for 2.6.23 be easily added to the existing version in > > such a way that you can demonstrate low-risk of regressions for > > 2.6.18? By this I mean the changes are small and easy to review, > > and perhaps are #ifdef'd to avoid changing behavior on 2.6.18. > > 3) If we really need a new upstream version of the module, can you > > include the source to both modules such that the "old" version is > > used for 2.6.18, and the new for 2.6.23? > > 4) As a last resort, we could consider adding a second package, > > e.g. ivtv-source-2.6.23. I don't really like this idea > > much because it seems pretty confusing for users. But, if prebuilt > > ivtv-modules packages are provided by one of the linux-modules- > > congolmeration packages, we can perhaps hide these details from > > them. > > > > Anyway, I'm glad to see people already considering the impact of this, > > thanks! > > It's actually not the module that needs to be updated. The problem is > that in 2.6.22, the ivtv kernel module moved into the upstream kernel, > so 2.6.23 includes a newer version of the ivtv module than the one > shipping in etch. But the ivtv-utils userspace package that ships in > etch is only compatible with the 0.8 kernel module; it needs to be > updated for compatibility with the 2.6.23 kernel.
ivtv-source still contains the ivtvfb driver, but that is only
compatible with the 2.6.2[23] version of ivtv.
However, as Marc says it is really the tools incompatibility which is
going to bite in terms of not breaking 2.6.18 support and those issues
aren't really addressed by #1-#3 above. A scheme with multiple binaries
(e.g. in /usr/lib/ivtv<version>) and a wrapper in /usr/bin might be
workable but seems like a big change for stable.
For a long while I've been maintaining the various branches out of
Debian as ivtvX.Y-{utils,source} and that seems to have gone down ok
with the users (well, no one has complained ;-)). I don't like #4 much
either but it might be simplest thing.
Need to think on it for a bit.
Cheers,
Ian.
--
Ian Campbell
Don't vote -- it only encourages them!
signature.asc
Description: This is a digitally signed message part
