Re: Unsing stable-backports as an ugprade path to stable+1
On Wed, 19 Jan 2022, Thomas Goirand wrote:
> I've just uploaded Ceph 16.2.7 to bullseye-backports, as it reached testing.
> Obviously, this is to allow using the latest version in Stable. However,
> whenever Ceph Quincy (ie: 17.2.x) will be released, I'm wondering if I should
> upload it to Unstable. Indeed, Ceph only support skipping a single version. As
> Bullseye contains 14.2.21, it will only support upgrading to 16.2.x.
In that case, you’ll need to ship 16.2.x in bookworm,
and bullseye-backports can only have packages from bookworm,
neither older nor newer.
Debian stables’ upgrade paths are so that no version may be skipped
(oldoldoldstable → oldoldstable → oldstable → stable → next stable),
and you may mix packages only from two adjacent releases (so, for
example, oldoldstable+oldstable *xor* oldstable+stable) and this is
only really supported for either during-upgrade scenarios or within
backports. (A kernel from release N will be usable with both N-1 and
N+1 so if you need to upgrade over two releases (e.g. oldoldstable
to stable), it’s not necessary to reboot twice: upgrade oldoldstable
to oldstable including its kernel, reboot, upgrade to stable. Or,
install oldoldstable-backports kernel and reboot before doing both
upgrades one after the other.)
This means that both bullseye → bookworm bullseye → bullseye-backports
→ bookworm must stay supported upgrade paths (with -sloppy in the mix,
things become even more interesting). That, and you must have version
parity between bullseye-backports and bookworm.
> So, if I am to upload Ceph Quincy (17.x.x, if you're following) whenever it is
> ready upstream, if Debian is to provide some kind of Stable to Stable+1 path,
> we must keep somehow a repository for our users to upgrade to 16.2.x, and then
This is not something you can do in Debian.
> Your thoughts?
Try to talk to upstream. Perhaps it’s possible to (at least locally
to the Debian packaging) support the extended upgrade path.
Otherwise, following current rules, ceph either isn’t suitable *at
all* for a stable Debian release (with all that follows) or will lag
behind in increasing amounts of versions.
In the sense of serving users, it *may* be possible to ship the last
version bullseye will upgrade to (16.x) as ceph and the latest version
(17.x or 18.x) as ceph17 or ceph18, so then the upgrade path looks as
follows (without backports in the mix):
• dist-upgrade from bullseye to bookworm upgrades ceph 14 to ceph 16
• ceph 16 shows a notice that it’s unsupported and that the user must
install the new ceph17¹ package instead
• user installs ceph17 17.x which takes over the configuration from
the ceph package and conflicts with it so it gets removed (this is
MAJORLY tricky to get right, and if you don’t get it right in the
first upload, it’ll be all but impossible to get right for users)
• bookworm+1 ships ceph17 18.x (or so) and ceph20 and you need to do
the whole thing again
① or ceph18 ofc
The security team would probably just consider the ceph package in
bookworm to be unsupported, but the release team is likely going to
loathe this approach (and users who don’t get the message will be
stuck on old unupgradable versions).
With backports in the mix, nothing changes. Users can do the switch
from ceph 14 to ceph 16 (and optionally to ceph17 17) within
bullseye-backports, assuming you’d upload ceph 16 (and ceph17) to
bullseye-backports, but both ceph 16 and ceph17 17 would still need
to be in bookworm, both for users who don’t choose to use backports
and for the package to be eligible for backports in the first place.
I think everyone involved would be served better if you can talk to
upstream and have them figure out a solution that works with Debian’s
release cycles. (And incidentally, the Derivate-that-must-not-be-named
since their LTS releases also don’t permit skipping, come out at about
the same frequency as stable Debian releases, and support upgrading
from one LTS to another skipping their three intermediate, nōn-LTS,
releases in between. This might raise the popcon if you need that kind
of argument for upstream.)
Good luck,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
╳ HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************
Reply to: