Re: Unsing stable-backports as an ugprade path to stable+1
On Wed, Jan 19, 2022 at 02:16:36PM +0100, Thomas Goirand wrote:
> The challenge here is that Ceph release cycle for 2 releases is a little bit
> shorter than Debian's 1 release cycle, so the risk is that Debian is always
> behind, and looses security support.
>
> Your thoughts?
You could do:
Debian N:
Package: default-ceph
Depends: ceph-X
Debian N+1:
Package: default-ceph
Depends: ceph-Z
Package: ceph-Z
Conflicts: ceph-Y, ceph-X
Description: ceph production package
Package: ceph-Y
Conflicts: ceph-Z, ceph-X
Description: ceph upgrade package
This package is only provided to allow for clean upgrades from Debian
N. Please do not use it for new installations!
Package: ceph-X
Conflicts: ceph-Y, ceph-Z
Description: ceph upgrade package
This package is only provided to allow for clean upgrades from Debian
N. Please do not use it for new installations!
And then ceph-Z could have a preinst that checks if there is a ceph-X
installation and error out, with instructions to remove default-ceph,
and do the upgrade with the help of the ceph-Y packages.
This is similar to what PostgreSQL does, although the upgrade strategy
there is somewhat less convoluted.
I realize that's a bit more work, but you'd need ceph-X and ceph-Y only
for upgrade support; you could make it clear that there is no security
support for those packages.
Alternatively, since you said that upstream talks to you quite a bit,
you could ask them if it would be possible for them to write the upgrade
logic in such a way that it can be installed and run separately. That
way you could keep *just* the upgrade logic for an older, unsupported
release in Debian, and ship that in a "ceph-old-upgrades" package or
some such that the regular ceph package can have in its depends or
recommends relationship.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Reply to: