On Thu, May 08, 2025 at 04:52:36PM +0200, Paul Gevers 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?
No, there would be no issue. > And in the reverse, if they would keep the old dovecot, but upgraded gsasl, > would that work for them? There would be no issue. > 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. The failure is only in the tests. I'm happy to do an NMU adding the missing version constraing to gsasl's debian/tests/control if that's useful. noah
