Re: Unsing stable-backports as an ugprade path to stable+1
On 1/24/22 15:36, Thorsten Glaser wrote:
On Mon, 24 Jan 2022, Thomas Goirand wrote:
too. Ceph is not the only part of Debian where something like that would
Correct. And that's probably the path I will choose as well: yet another
unofficial Debian repository in the debian.net namespace, for people to use as
But these aren’t part of Debian any more then…
upgrade path.
Hmm. At least put in a preinst into the normal package that refuses
upgrading from a version where upgrading from is not supported. Not
too happy with that though, as it’ll break upgrades between stable
releases :/ (does anyone know of a better version, except removing
ceph from bookworm?)
bye,
//mirabilos
Hi Thorsten,
Well, I'd be happy if I had any other solution, but apparently, there's
none. Anyway, we're not there yet, currently upstream has 16.2.x as
stable, and it will be supported for another 1.5 years, which will be
enough until Bookworm is released, so I can leave things as they are,
and it should be fine for another Debian cycle.
I'll see how it goes with upstream, and then we may re-open the discussion.
Your advice about checking what previous version was installed in the
preinst is a good advice. I'll see if I can implement it.
On 1/24/22 19:17, Rebecca N. Palmer wrote:
> (For ceph in particular the risk of "getting it wrong = data
> loss/corruption" might be high enough that it's better to not ship
> ceph in stable, but it might not be the only package where upgrades
> skipping 2-3 years of releases are unsupported.)
As I wrote, Debian is not significantly late in Ceph release so what you
wrote becomes the solution.
On 1/24/22 19:08, Bernd Zeimetz wrote:
> Hi,
>
> On Mon, 2022-01-24 at 15:21 +0100, Thomas Goirand wrote:
>>
>> Correct. And that's probably the path I will choose as well: yet
>> another unofficial Debian repository in the debian.net namespace, for
>> people to use as upgrade path.
>
> to be honest I don't think thats needed, at least not as long is
> upstream is building Debian packages, it might eben make more sense to
> send PRs for upstream to keep their debian folder in a better shape.
>
> Please talk to upstream again, and in case there is no long term
> solution, I'd suggest to strip the package down to whatever is needed
> to make the reverse (build) dependencies happy.
>
>
> Bernd
Thanks for your contribution to this thread.
About upstream packaging: I have learned how to *NOT* trust it, because
it's not always there. For example, at some point, they stopped
releasing for Buster because they mistakenly used GCC 7 specificity
which made it impossible to support in our stable (I'm not sure about
the Debian release name and GCC version, but I'm sure that this happened
upstream, and users were left without upstream Debian packaging
support). This also happened later with another combination of release
numbers. I've heard someone complaining that upgrade for Buster +
Octopus upstream packaging was a dead end too.
It will happen again. As a Debian user, I do not want to be in such a
position. As maintainers, if we care about Debian users, we *MUST*
provide an upgrade path.
Right now, it looks like maintaining Pacific in Bookworm should be
doable, so I'll withdraw this thread $subject a possibility, and see how
it goes. If there's no other way, I'll do that through unofficial (or
semi-official like fastrack) repositories, but I'll try to avoid it (and
first, engage with upstream).
Cheers,
Thomas Goirand (zigo)
Reply to: