Re: Proposed (lib)curl switch to openssl 1.1
- To: Julien Cristau <jcristau@debian.org>
- Cc: Alessandro Ghedini <ghedo@debian.org>, firefox@packages.debian.org, openjfx@packages.debian.org, Niels Thykier <niels@thykier.net>, Sebastian Andrzej Siewior <sebastian@breakpoint.cc>, sx@packages.debian.org, cargo@packages.debian.org, slcurl@packages.debian.org, fpc@packages.debian.org, xmltooling@packages.debian.org, curlpp@packages.debian.org, r-cran-rcurl@packages.debian.org, libapache2-mod-auth-cas@packages.debian.org, Adrian Bunk <bunk@stusta.de>, Stepan Golosunov <stepan@golosunov.pp.ru>, tclcurl@packages.debian.org, firefox-esr@packages.debian.org, curl@packages.debian.org, wpa@packages.debian.org, Jan Niehusmann <jan@gondor.com>, netsurf@packages.debian.org, criticalmass@packages.debian.org, ruby-curb@packages.debian.org, zurl@packages.debian.org, cmake@packages.debian.org, hhvm@packages.debian.org, chromium-browser@packages.debian.org, netcdf@packages.debian.org, lastpass-cli@packages.debian.org, icedove@packages.debian.org, libwww-curl-per@bendel.debian.org, l@packages.debian.org, Ian Jackson <ijackson@chiark.greenend.org.uk>, 858398@bugs.debian.org, r-cran-curl@packages.debian.org, debian-release@lists.debian.org, lua-curl@packages.debian.org
- Subject: Re: Proposed (lib)curl switch to openssl 1.1
- From: Sam Hartman <hartmans@debian.org>
- Date: Thu, 11 Jan 2018 08:46:39 -0500
- Message-id: <[🔎] tslbmi0v77k.fsf@suchdamage.org>
- In-reply-to: <[🔎] b4e74ff9-6ac3-54c1-c510-34a4cfd849bf@debian.org> (Julien Cristau's message of "Thu, 11 Jan 2018 10:29:02 +0100")
- References: <23062.60934.23858.571216@chiark.greenend.org.uk> <20171202170939.x5a25grq5sa7w4wl@betterave.cristau.org> <20180110235920.GA18737@pinky> <[🔎] b4e74ff9-6ac3-54c1-c510-34a4cfd849bf@debian.org>
>>>>> "Julien" == Julien Cristau <jcristau@debian.org> writes:
>> Following discussion on the ticket (#858398) it was suggested to
>> follow the strategy used for the GCC 5 C++ ABI transition, that
>> is, rename the libcurl package and add Conflicts+Replaces for teh
>> old package.
>>
Julien> I still think that is a terrible idea and we're better off
Julien> with both a new SONAME and a new package name. Conflicts in
Julien> core libraries turn the upgrade path to hell.
I'd urge the project to find some way of considering both the impact to
our upgrade process and the impact of diverging the soname for our
users, including users who use non-packaged binaries of various kinds.
I don't know what the right answer is, but it sounds like everyone
involved in this discussion is focused on the issues that matter most
to them, and not at balancing the overall picture.
We're seeing a lot of short messages focused on one position like
Julien's above, and that concerns me significantly.
There really are tradeoffs on both sides here.
--Sam
Reply to: