Re: openafs in etchnhalf
On Tue, Jun 17, 2008 at 11:11:25AM -0700, Russ Allbery wrote:
> 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).
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
Reply to: