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.
- Marc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
