[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#796345: redhat-cluster/libdlm + lvm + perl transition



On Mon, Dec 14, 2015 at 06:26:34PM +0100, gregor herrmann wrote:
> On Mon, 14 Dec 2015 11:15:03 +0100, Emilio Pozuelo Monfort wrote:
> 
> > >> Dominic Hargreaves <dom@earth.li> writes:
> 
> > >>> If not then perhaps that should just be dropped from the
> > >>> redhat-cluster package ASAP [...] -- of course, since redhat-cluster
> > >>> FTBFS, this would have to be done by the release team manually
> > >>> removing (just) libccs-perl from testing. Is this feasible?
> > 
> > Not really. At least not AFAIK, and it'd be hackish and ugly if it was possible.
> > It'd be nice if the FTBFS got fixed instead. If it's too difficult to make it
> > build with GCC 5 (I guess it isn't, but...) then as a temporary workaround you
> > could make it build with GCC 4.9.
> 
> The build doesn't even get that far, it fails due to the corosync
> changes, cf. #804590.

Just so everyone is on the same page, the redhat-cluster FTBFS is now
the only thing blocking a 500+ package Perl transition we've been working
on for half a year.

It looks to me like the corosync v1->v2 API changes are indeed significant
enough that making redhat-cluster build again is non-trivial.

So the proper way out seems to be a separate libdlm source package, as
discussed in [1]. Ferenc, do I understand right that a new pacemaker
package is a blocker for this? Is that because the current pacemaker
would be broken by the libdlm update?

FWIW I see Ubuntu already separated libdlm out back in 2013. Maybe that
work helps a bit?

Some other hackish and ugly things we've discussed:

- is it technically possible to force the transition through and leave
  libccs-perl uninstallable in testing? Or do britney et al. enforce
  the installability so that it can't be overridden?

- as clearly nobody cares about libccs-perl itself, would hijacking
  the libccs-perl binary package with a (more or less dummy) new source
  package work wrt. testing migration?

- reintroducing corosync v1 temporarily to get redhat-cluster to build
  would work AFAICS but it's *very* ugly...

- temporarily dropping the clvm binary package until libdlm can be built
  again seems doable, but as #697676 shows something like this was done
  for wheezy and had to reverted due to user demand, so presumably Bastian
  wouldn't be thrilled to try it again

Other ideas would be welcome too.

[1] https://lists.alioth.debian.org/pipermail/debian-ha-maintainers/2015-December/004615.html
-- 
Niko Tyni   ntyni@debian.org


Reply to: