Re: Bug#1132617: mesa: update debian trixie-backports to 26.0.x

Hi,

Am 17.05.26 um 09:10 schrieb Paul Gevers:
> Hi,
>
> On 5/17/26 07:36, Andreas Metzler wrote:
>> On 2026-05-16 Charlemagne Lasse <[email protected]> wrote:
>>> Can somebody check if my understanding is correct and packages
>>> uploaded to Debian backports should get updated when a new version
>>> hits testing?
>>
>> Good morning,
>>
>> I do not think it is that simple. The main point is that bpo is not
>> fire-and-forget. - If you upload you will need to support it. However
>> that does not imply that bpo must strictly track testing. There can be
>> reasons to have foo v2 in stable and keep bpo at v3 although v4 is
>> available in testing. e.g. v4 breaks a huge number of rdeps but v4
>> doesn't. Or if v4 is at 4.0 and experience shows that a little bit of
>> extra waiting time before upgrading foo has not hurt in there past.
>>
>> Imho a bpo maintainer may make judgement calls like these.
>
>
> That's not my understanding of [1] this:
> """
> This means, you have to keep track of the changes in unstable, update your backport when a new version enters testing...
> """
> I've always understood that backports is supposed to follow testing, not some older version that the maintainer likes. If there are worries about the backport, there should be worries about it migrating to testing too (and it should have been hold in unstable longer, or should have been uploaded to experimental). If it breaks stuff, a +reallyv3 version should be in unstable/testing too. I assume the backport ftp-masters can confirm.
>
I've only ever did this on changes where the bpo user has an effect on. For sid-only transition changes there's no need to update a backport.

(see e.g. liborcus' backport, anything newer than what is backported is for the libparquet filter which won't be enabled in backports as there is no apache-arrow there, and backporting that one is nozt possible without backporting cython3 and whatever else...)

The instructions even say "Don't backport minor version changes without user visible changes or bugfixes"


And if a new mesa, as implied, breaks stuff and needs a big transition, this falls into the


"That said, Debian Backports Policy does not allow backports of libraries that would break all dependent packages in stable (eg: new Qt 5.x releases), and by virtue of this, Debian Backports are considered generally safe when used as intended on an individual package basis."


Regards,


Rene