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

Paul Gevers <[email protected]> Sun, 17 May 2026 10:27:29 +0200

Newsgroups	gmane.linux.debian.devel.x
Message-ID	<195ef763-5cc4-43e4-a29f-001b0fd0f782__36231.1176069611$1779006565$gmane$org@debian.org>

Hi Rene,

On 5/17/26 09:57, Rene Engelhard wrote:
> Am 17.05.26 um 09:10 schrieb Paul Gevers:
>> """
>> 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...)


While I think this isn't according to the letter of the comment I 
quoted, I think it is according to the spirit. What you describe here is 
quite different from the v3 vs v4 example of the mail I replied to.

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


Hmm, that sentence is a bit ambigue. I was reading it as "don't backport 
a package where the delta between testing and stable is without user 
visible changes or bugfixes" but I see what you mean too. (Maybe the 
backports ftp-masters can clarify the sentence on the web page).

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


So it should be removed from bpo instead of not updated? This is more of 
a question to those that are in charge of the backports policy.

Paul

OpenPGP_signature.asc (application/pgp-signature, 585 B)