Re: kernels in etch and compatibility with modules packages
* Ian Campbell [Tue, 27 Jun 2006 20:07:59 +0100]:
> [Please CC as I am not subscribed.]
[Added -release in case some more comments are needed.]
> I am the maintainer of the IVTV driver packages. The IVTV upstream have
> a scheme where the 0.6.x releases are for use with the 2.6.16 kernels,
> 0.7.x goes with 2.6.17 etc. There is an older 0.4.x series which works
> with 2.6.15 and earlier.
> I have unfortunately allowed the 0.6.x package to propagate into Etch,
> which currently has a 2.6.15 kernel that the IVTV packages cannot work
> with. It seems that 2.6.16 will not be going into Etch anytime soon
> due to the freeze, is that correct?
Not really, which should be good news for you. :) The kernel team has
put work in coordination with the release team to ensure that 2.6.16
images enter testing as soon as possible. Now, there are in sid two
source packages, linux-2.6 (providing .17) and linux-2.6.16, which is
expected to enter testing soon:
> Given that 2.6.16 won't be going in I think the best thing for me to do
> would be to file a bug asking for the current IVTV package to be removed
> from testing.
Would be the right to do if it was necessary. ;-)
> However, does anyone know a more elegant way than filing
> an RC bug to stop the 0.6.x package propagating again (and the same
> problem occurring in the 2.6.17/0.7.x time-frame)? I don't think there
> is a kernel package I can sensibly depend on since people may build from
> upstream source. Would a build-depends make sense, even though it isn't
> strictly true?
The RC bug is the way to go. As you say, you can't add a dependency, and
build-depends would not do it, since propagation to testing does not
take them into account, only dependencies.
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
I don't want to achieve immortality through my work. I want to achieve
immortality through not dying.
-- Woody Allen