On Tue, Jun 17, 2008 at 11:11:25AM -0700, Russ Allbery wrote: > 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).
If I understand this correctly, that would mean that etch users would be forced to move to the new module code, right?. I don't doubt that it would work just fine, but objective #1 is to minimize risk to existing etch users. > 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. Why would it need to conflict replace? Could they install into separate locations? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
