[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unsing stable-backports as an ugprade path to stable+1



On Thu, 2022-01-20 at 00:12 +0100, Thorsten Glaser wrote:
> 
> Try to talk to upstream. Perhaps it’s possible to (at least locally
> to the Debian packaging) support the extended upgrade path.

I think that was tried, just not sure what the outcome was.


> 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.

Dropping ceph is also not an option, as it would remove ceph supposert from
qemu, which is something we absolutely need to avoid.

Maybe itmight be an option to strip ceph down the the libraries needed for
that? Not sure, though.



> 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).

That would also be a maintenance hell.


> (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, [....]
> 

U* is one question, the other one is how RedHat is supporting Ceph and how
their upgrade path looks. Although they are a bit more flexible I guess as
they have their own ceph repositories and support ceph over different
releases.

Maybe Debian (finally) needs to add support for per-package repositories,
too. Ceph is not the only part of Debian where something like that would make
sense, although that discussion is not for this list.


-- 
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


Reply to: