dann frazier <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To unsubscribe, send mail to [EMAIL PROTECTED]