Re: openafs in etchnhalf
dann frazier <dannf@debian.org> writes:
> On Tue, Jun 17, 2008 at 10:48:45AM -0700, Russ Allbery wrote:
>> I'm quite happy to upload new packages for etchnhalf, but I'm afraid
>> they'd have to be just that -- packages of a newer upstream. The
>> upstream changes to support newer kernels are far too comprehensive for
>> me to be able to isolate them and apply them separately, and the result
>> would be poorly-tested and less stable than going to the current
>> packages from Debian testing.
>> So... I guess my question is, what is the policy for etchnhalf for
>> packages that involve kernel modules? Is it fair game to upload a new
>> upstream version, unlike the normal stable release policies?
> I think the answer would have to be creating a *new* package (e.g.,
> openafs-source-etchnhalf) that can be installed next to the existing
> etch package. Otherwise we risk introducing regressions w/ the 2.6.18
> kernel.
True, although upstream does continue to test with older kernels, so I'm
not *too* worried. But the risk is there.
The only relevant part of the openafs package affected is the
openafs-modules-source arch: all package. I'm fairly sure (although would
need to test) that installing a new kernel module built from the lenny
openafs-modules-source package will work fine with an openafs-client
package from the current etch. (Sometimes there are mismatches between
afsd and the kernel, but I don't think any have happened since etch.) So
we could add to etchnhalf a new openafs-modules-source source package that
supersedes the binary package built from the openafs source package,
although I don't know how confused that would make dak (particularly if we
have to do a security update of openafs).
Alternately, we could provide an openafs-modules-source-etchnhalf package
that conflicts and replaces openafs-modules-source, although that seems a
little weird to me.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: