Re: 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
Reply to: