XPost: linux.debian.devel.release

On Thu, Apr 24, 2025 at 12:30:41PM +0200, Paul Gevers wrote:

Sorry taking so long to reply. I assumed because you filed a transition bug that there was a regular SONAME bump involved.

It's likely my fault for not highlighting the unusual nature of dovecot
when filing the bug.

I see that the dovecot-core ships libraries, but it looks like they
didn't bump SONAME. So how is this supposed to work in the dovecot
ecosystem? Isn't the package name supposed to change when SONAMEs
change (Debian policy) and isn't ABI breaking (which is implied by the transition request and suggested by your Provides) not a reason to
bump SONAME? As this is a unconventional transition, I'm not
comfortable to judge.

In the past, I don't believe we've actually treated dovecot version
bumps as transitions, despite the impact that they have on reverse
builddeps. I chose to do that for the 2.4 change because, at the time I
opened the request, we were just starting the freeeze and I didn't want
to risk complicating things with uncoordinated changes.

Dovecot's relationship with its reverse builddeps is somewhat inverted
from normal library providers. The reverse builddeps are plugins to the dovecot process, so they build shared libraries that are loaded by
dovecot with dlopen(). They don't actually link against any
dovecot-provided shared libraries at build time (in fact, the -dev
package doesn't include any libraries). The binary interface is the
dovecot process itself, plugins explicitly declare any dovecot plugin dependencies they may have, and symbol resolution happens at runtime.
The ABI version and API version are considered the same thing, and are
bumped with every upstream release.

See https://doc.dovecot.org/2.4.1/developers/design/plugins.html

I'm unhappy with removing dovecot-antispam [1] so late for a transition especially as I don't see a warning to its maintainers/users [2]. The unconventional library handling (via the dovecot-abi-*.abiv* Provides from dovecot-core IIUC) makes me want to defer to Release Team member colleagues who handle much more transitions than I do.

I did notify the maintainer privately, before realizing that they seem
MIA, but didn't follow up with a bug report. I've now opened #1104033
for better visibility.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104033

noah

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sat, Apr 26, 2025 at 12:05:31PM +0200, Paul Gevers wrote:

For the record of this bug, there's a piuparts issue (tagged pending): 1104047.

Please also help the reverse dependencies to fix their autopkgtests (filing bugs and/or providing patches). It seems that the new dovecot requires an update to configuration files. Is that worth mentioning in the release-notes too?

Yes, I'll post the release-notes MR tomorrow.

autopkgtests fixes are in the works. When reporting bugs against the
impacted packages, what severities and/or tags are most appropriate?
RC with 'sid' tag seems like it could be appropriate, but maybe not
necessary?

Thanks
noah

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.release

On Sat, Apr 26, 2025 at 12:05:31PM +0200, Paul Gevers wrote:

Hi Noah,

On 26-04-2025 10:03, Paul Gevers wrote:

For the record of this bug, there's a piuparts issue (tagged pending): 1104047.

Please also help the reverse dependencies to fix their autopkgtests (filing bugs and/or providing patches). It seems that the new dovecot requires an update to configuration files. Is that worth mentioning in the release-notes too?

All rdeps have fixed autopkgtests at this point. Only
dovecot-fts-xapian isn't uploaded yet (pending maintainer action on https://salsa.debian.org/debian/dovecot-fts-xapian/-/merge_requests/3)

One of these rdeps actually found a dovecot regression with its
autopkgtests, which is now fixed, so that's nice...

noah

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)