[pkg-squid-devel] Bug 791117: libecap vs libstdc++6 transitions

[Amos Jeffries]

On 4/08/2015 11:59 p.m., Luigi Gangitano wrote:
> 
>> Il giorno 04/ago/2015, alle ore 13:26, Amos Jeffries <squid3 at treenet.co.nz> ha scritto:
>>
>> On 4/08/2015 11:14 p.m., Luigi Gangitano wrote:
>>>
>>>> Il giorno 04/ago/2015, alle ore 12:57, Amos Jeffries <squid3 at treenet.co.nz> ha scritto:
>>>>
>>>> BUT, in this particular circumstance do we actually need a full transition?
>>>>
>>>> * squid 3.5 is the only thing using libecap3.
>>>>
>>>> * squid 3.5 is not yet in stretch.
>>>>
>>>> IMHO ...
>>>>
>>>> If both rebuild together (depends on cppunit availability) together
>>>> there should not be any noticable issues. What hits stretch will be the
>>>> v5 versions of both packages.
>>>
>>> Ok, so: I see cppunit patch in BTS with priority normal. Will be fixed shortly. If we upload libecap_1.0.1-2 with no package name change we should at least make sure that squid3 does not transition to stretch before it is rebuilt against it. I would add an RC bug on squid3 depending on 791013 (cppunit transition).
>>>
>>
>> I pass you this somewhat garbled attempt to do that between the piuparts
>> RC being removed and your feedback:
>> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794536>
> 
> Uhm, I’m not sure you reached your goal:
> 
> https://qa.debian.org/excuses.php?package=squid3
> 
> Maybe it should be RC and not serious.
> 

serious was listed as one of the RC levels, and same was used on the
other RC bug that blocked it going in this past week.

I did somehow get it linked to the wrong version. Now linked correctly
(I think - it shows up properly in BTS anyhow). The excuses page is not
updating fast enough (6hrs?), so we may not know for a while if it was
quick enough.



>>>> A "Breaks: libecap3 (<= 1.0.1-1)" on libecap3 should prevent people
>>>> having a partial upgrade in sid.
>>>
>>> You already corrected this. :-) I fear that if it Breaks: squid3 < 3.5.7 it will not be accepted in sid and we are in a catch22 situation. Probably we should just avoid this and add an RC bug to squid3 to block it from transitioning in testing.
>>>
>>
>> Not squid3, just squid. And it could be exactly (= 3.5.6-1) even now
>> that I think about it a few seconds more.
>>
>> Ah, well. Your call in the end anyway.
> 
> Let’s go with this solution. I’ll write an explanation in the bug report on why we are not changing the package name.
> 
>>>>> - there is no SONAME change in upstream, so I’m going with libecap3v5 it this is ok for you. I don’t want to mess with upstream SONAME.
>>>>>
>>>>
>>>> I just think the *v5 bit looks ugly and we're not exactly dealing with
>>>> pre-existing uses of the library.
>>>
>>> I took some hints from other packages. The v5 change can be limited to package name, so it’s no big deal.
>>>
>>> Attached is my current diff.
>>>
>>
>> In the changelog: libecap2v5 -> libecap3v5
> 
> Thanks.
> 

Thats me done for the day. I just have to wait it out now.

Thank you.

Amos