Hi, On 08-05-2025 16:39, Simon Josefsson wrote:
I'm not so sure about my statement above, is a Breaks: appropriate when it is not breaking the package build but only breaks debci for that package? Seems like that ought to be handled by gsasl/debian/tests/control Depends:.As for test vs user-facing, as far as I understand, nothing except the self-test changed in gsasl here, and dovecot upstream created a patch to make things work with gsasl and that is in the Debian devecot 2.4 package. I haven't reviewed details to see if dovecot really was buggy here or if they decided to just silence the problem by patching things on their side, but I'm also not sure that matters. The gsasl patches had nothing to do with the interop failure, it was just to make the gsasl self-test start again after dovecot changed their configuration syntax.
What I mean is, that if a *user* would keep an older version of gsasl and would install the new dovecot, would they see (some) broken behavior or not? And in the reverse, if they would keep the old dovecot, but upgraded gsasl, would that work for them? In either case it needs a versioned relation. If the failure is only in the test (which I think I'm reading in your explanation above), one of the two relations will help the migration software to figure out what tests to run, but for test only failures some maintainers feel like that's overkill. You can add the versioned relation also to the *test* dependencies, but the migration software doesn't inspect that itself. For the cases where maintainers prefer not to add the relations for test only failures, I can schedule the combination manually.
Hope this helps too. Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
