[Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 15/12/15 21:27, Niko Tyni wrote:
> 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 at 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?

That's possible, in exceptional circumstances. Obviously I would prefer not to
do that.

> - 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?

Let's not do that.

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

Let's not do that.

> - 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

Right. That shouldn't be necessary.

If redhat-cluster doesn't get fixed in time, I guess we'll just make libccs-perl
uninstallable.

Let's do this.

Cheers,
Emilio