Bug#988963: libgc1c2: please drop obsolete Conflicts/Replaces on libgc1 in buster, it interferes with upgrades to bullseye

Control: reassign -1 libgc1c2 1:7.6.4-0.4
Control: retitle -1 libgc1c2: please drop obsolete Conflicts on libgc1

Dear libgc maintainers,

tl;dr: it was discovered that in certain cases, a full-upgrade from
buster to bullseye ends with certain packages not upgraded. We found out
that's caused by a circular Conflicts. libgc1c2 (buster) conflicts with
libgc1 (a package long gone; 2005), and libgc1 (bullseye) conflicts with
libgc1c2. The reasonable way to fix this is in buster.

On 27-05-2021 20:25, Bill Allombert wrote:
> On Thu, May 27, 2021 at 09:48:29AM +0200, Paul Gevers wrote:
>> On 26-05-2021 23:21, Bill Allombert wrote:
>>> On Wed, May 26, 2021 at 07:50:53PM +0000, Holger Levsen wrote:
>>>> On Wed, May 26, 2021 at 12:00:46PM +0200, Bill Allombert wrote:
>>>>> One way to fix that is to update libgc1c2 in stable to not 
>>>>> Conflict/Replaces with libgc1.
>>>>  
>>>> while this is true, this is also not the most desireable fix, because
>>>> it should be possible to update from *any* stable installation
>>>> to the next stable, not just from the latest stable point release.
>>>
>>> I agree with you, but this is a general issue with circular dependencies
>>> (and circular conflicts) that they can only be fixed cleanly by
>>> updating stable and not testing. 
>>> That is why I have always strongly recommended to avoid them.
>>>
>>> (We could of course fix it in testing by renaming libgc1 to libgc1c4 or 
>> whatever
>>> but that would create a much larger disruption than removing a useless Conflict
>>> from stable).
>>
>> Do I understand you correctly that we're ready to reassign this bug to
>> libgc1c2 and ask for the fix in buster?
> 
> To me there are two options:
> - do nothing and document this in the release note
> - fix it in stable.
> but this is to the release team to decide.
> 
> We can reassign this bug to libgc1 but it is likely to be ignored
> because it cannot be fixed in testing.

I'd expect our Stable Release Managers to be fine with an update like
this. I can even do it via an NMU if that's preferred. Please reassign
to the release-notes pseudo package if fixing this is unacceptable to
you, but please elaborate why in that case.

Paul