Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails
Control: tag -1 - moreinfo
Hi,
On 13:50 Thu 02 Aug , Andreas Beckmann wrote:
> Control: tag -1 moreinfo
> Control: severity -1 important
>
> On 2018-08-02 09:00, Apollon Oikonomopoulos wrote:
> > 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
>
> Let's wait for libcurl3 to leave testing, that might clean up the
> upgrade path automatically. The pure existence of libcurl3 in testing
> causes trouble on a few other upgrade paths as well, since it is not
> always considered as a candidate for removal.
>
> If that doesn't work, ganeti might need to add Breaks or Conflicts
> against ganeti-{haskell,htools}-2.15 to ensure they are removed before
> the new ganeti is unpacked. This should hopefully be resolvable without
> updating the version in stable.
Unfortunately this won't help: ganeti-*-2.15 and ganeti-*-2.16 are
designed to be co-installable (hence the different package names)
and in fact they must both be installed and configured for the cluster
upgrade to take place. IOW, the intended behavior when dist-upgrading is
to end up with *both* sets of packages installed and configured, and
Breaks/Replaces defeats this purpose.
As libcurl4 and libcurl3 conflict, a set of packages that collectively
depends on both will not be installable. So we'll either need a version
of ganeti-*-2.15 that depends on libcurl4 in buster (because we can't
have it in stretch, as stretch doesn't have libcurl4), or a version that
uses a different libcurl variant in stretch (and buster presumably).
I tend to think the former is more robust.
Apollon
Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails
Control: tag -1 moreinfo
Control: severity -1 important
On 2018-08-02 09:00, Apollon Oikonomopoulos wrote:
> 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
Let's wait for libcurl3 to leave testing, that might clean up the
upgrade path automatically. The pure existence of libcurl3 in testing
causes trouble on a few other upgrade paths as well, since it is not
always considered as a candidate for removal.
If that doesn't work, ganeti might need to add Breaks or Conflicts
against ganeti-{haskell,htools}-2.15 to ensure they are removed before
the new ganeti is unpacked. This should hopefully be resolvable without
updating the version in stable.
Andreas
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
Bug#905176: ganeti: fails to upgrade from 'stretch': removal of ganeti-{haskell,htools}-2.15 fails
Package: ganeti Version: 2.16.0~rc2-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'stretch'. It installed fine in 'stretch', then the upgrade to 'buster' fails. >From the attached log (scroll to the bottom...): Selecting previously unselected package ganeti-2.16. Preparing to unpack .../48-ganeti-2.16_2.16.0~rc2-4_all.deb ... Unpacking ganeti-2.16 (2.16.0~rc2-4) ... Preparing to unpack .../49-ganeti_2.16.0~rc2-4_all.deb ... Unpacking ganeti (2.16.0~rc2-4) over (2.15.2-7+deb9u2) ... (Reading database ... (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 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) ... Errors were encountered while processing: ganeti-htools-2.15 ganeti-haskell-2.15 cheers, Andreas ganeti_2.16.0~rc2-4.log.gz Description: application/gzip
