[ Adding the release team in the loop ] Hello Andreas,
Thanks for the report. On 11:49 Wed 01 Aug , Andreas Beckmann wrote: > (Reading database ... 7847 files and directories currently installed.) > Removing ganeti-htools-2.15 (2.15.2-7+deb9u2) ... > dpkg: error processing package ganeti-htools-2.15 (--remove): > installed ganeti-htools-2.15 package pre-removal script subprocess > returned error exit status 30 > Removing ganeti-haskell-2.15 (2.15.2-7+deb9u2) ... > dpkg: error processing package ganeti-haskell-2.15 (--remove): > installed ganeti-haskell-2.15 package pre-removal script subprocess > returned error exit status 30 This is the prerm script of ganeti-htools-2.15 and ganeti-haskell-2.15 failing because ganeti 2.16 has not been configured yet, and so the active version is still 2.15. Ganeti is a clustered service and all nodes must be running the same minor version. Ganeti includes a mechanism to perform cluster-wide upgrades itself, which works by having multiple minor versions co-installed (hence the versioned package names) and calling `gnt-cluster upgrade', after which all nodes are switched to the new version in a coordinated fashion. This is a bit similar to the way postgres packages work, but in a multi-node setup. Unfortunately all of this breaks because of the libcurl3 -> libcurl4 transition in buster: > dpkg: libcurl3:amd64: dependency problems, but removing anyway as > you requested: > ganeti-htools-2.15 depends on libcurl3 (>= 7.16.2). > ganeti-haskell-2.15 depends on libcurl3 (>= 7.16.2). > Removing libcurl3:amd64 (7.52.1-5+deb9u6) ... The 2.15 packages depend on libcurl3 which is conflicted and replaced by libcurl4. As the 2.15 packages do not exist in buster, APT has to remove them together with libcurl3. For the reasons behind the conflict between libcurl4 and libcurl3, see #858398. Now, I could "fix" this for piuparts by allowing the packages to be uninstalled, no questions asked, *but* this would just cause user clusters to break on stretch → buster upgrades. Given that in #858398 it was decided not to do a SONAME bump for libcurl4 (which would have avoided the problem in the first place), the way I see it, there are two possible solutions: 1. Do a *stable update* for ganeti, rebuilding it against curl/gnutls (possibly after doing so for unstable as well). Note that the original reasons for using OpenSSL (#751886) should in theory be resolved, since GHC does not take over GMP heap management as of 7.10. 2. Upload a new ganeti-2.15 source in unstable, building *only* the versioned binary packages (ganeti-haskell-2.15 and ganeti-htools-2.15) which will depend on libcurl4 and will be used only to facilitate upgrades from stretch. ganeti-2.15 will be removed from unstable after buster is out. I'm not a big fan of changing the crypto implementation on a stable update, especially since there have been issues in the past. OTOH, maintaining 2.15, even at best-effort level, for another stable release is not ideal either. Finally, I want to stress again that the root cause of all this is the flawed libcurl3 → libcurl4 transition: if the OpenSSL API changes the library's ABI, it should be part of the library name, just as we distinguish between curl/gnutls and curl/nss. A Conflicts/Replaces between libraries - especially without a Provides - is a clear sign that something's very wrong. I do realize that ganeti is a corner-case, since the versioned packages for 2.15 only exist in stretch and not in buster, but still this will also affect any locally-built or 3rd-party packages as well. Does anyone from the release team have an opinion on any of the above? Regards, Apollon