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

[Luigi Gangitano]

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

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

L

--
Luigi Gangitano -- <luigi at debian.org> -- <gangitano at lugroma3.org>
GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26
GPG: 4096R/2BA97CED: 8D48 5A35 FF1E 6EB7 90E5  0F6D 0284 F20C 2BA9 7CED