Re: Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails
[ 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
Reply to: