Marvin Renich writes:
> Thanks for this and the rest of your explanation.
> I'm not convinced that this shouldn't have resulted in an SONAME bump,
> and Steve Langasek also seems to think this should have been handled
> differently, but everyone else seems to be happy with the current
> solution
* Russ Allbery [180602 20:30]:
> The core reasons are summarized fairly succinctly here, though:
>
> https://salsa.debian.org/debian/curl/merge_requests/2
Thanks for this and the rest of your explanation.
I'm not convinced that this shouldn't have resulted in an SONAME bump,
and Steve Langa
Marvin Renich writes:
> * Russ Allbery [180602 18:24]:
>> Adrian is of course correct.
>> The libcurl situation is exceptional and warranted a project-wide
>> discussion looking for cleaner migration paths (to no avail), so I
>> think
> Okay, I must have missed this discussion. Can you point
* Russ Allbery [180602 18:24]:
> Adrian is of course correct.
>
> The libcurl situation is exceptional and warranted a project-wide
> discussion looking for cleaner migration paths (to no avail), so I think
Okay, I must have missed this discussion. Can you point me to the
thread (on debian-deve
Adrian Bunk writes:
> On Thu, May 31, 2018 at 12:37:00PM -0400, Marvin Renich wrote:
>> libcurl4 conflicts with libcurl3, which violates the stated purpose of
>> the "must" clause at Policy 8.1 (to allow multiple versions of a shared
>> library to be co-installable), even though it doesn't violat
On Thu, May 31, 2018 at 12:37:00PM -0400, Marvin Renich wrote:
> Package: libcurl4
> Version: 7.60.0-2
> Severity: serious
>
> libcurl4 conflicts with libcurl3, which violates the stated purpose of
> the "must" clause at Policy 8.1 (to allow multiple versions of a shared
> library to be co-install
6 matches
Mail list logo
