I commented at salsa.d.o, but for consistency, I am resending my comment here:
The conflict here means that all r-depends will have to migrate at once, and absolutely no backports would be possible. I wish there would be a way where libcurl3 and libcurl4 would be co-installable, but so far I haven't come up with anything that would make it possible and still align the packages with upstream names. The fact that the symbols were versioned with GNUTLS_*_3 complicates the transition even more. But I guess it's a good time to finally bite the bullet and finish the transition, I just wish there would be a less intrusive way. Ondrej -- Ondřej Surý <ond...@sury.org> On Thu, Jan 11, 2018, at 00:57, Alessandro Ghedini wrote: > On Sun, Dec 17, 2017 at 11:16:29PM +0200, Adrian Bunk wrote: > > On Fri, Dec 08, 2017 at 05:44:55PM +0100, Ondřej Surý wrote: > > > Hi, > > > > > > just innocent bystander here with an observation: > > > > > > These two options: > > > > > > a) > > > > I do agree it's the correct solution though, and it would be a good > > > > opportunity > > > > to finally sync SONAME with upstream > > > > > > b) > > > > Because of 1 I think we should change the package name (and SONAME) for > > > > libcurl3. I don't think 2 is appropriate. > > > > > > are mutually exclusive, so even if we rename the share library packages > > > to libcurl4*, they would have to conflict with libcurl3* because they > > > would contain same files. > > > > > > And the SONAME is already libcurl.so.4 (at least on stretch): > > > > > > $ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME > > > SONAME libcurl-gnutls.so.4 > > > SONAME libcurl-gnutls.so.4 > > > SONAME libcurl-gnutls.so.4 > > > SONAME libcurl.so.4 > > > SONAME libcurl.so.4 > > > SONAME libcurl.so.4 > > > > > > So in this case, unfortunately, bumping the SONAME is actually something > > > different than changing package name to match to SONAME of the library. > > >... > > > > Similar to all the v5 postfixed packages in Debian for C++ ABI changes > > in GCC 5, what matter here is actually not the SONAME but the package > > name and that the new package conflicts with the old package. > > > > This is sufficient to fix the issue for all packages using curl. > > > > And different from breaks on specific packages, it will also force an > > upgrade of packages from backports. > > > > Non-packaged software is a different topic, but the whole OpenSSL > > situation in stretch is already a mess for that. > > > > This whole transition looks pretty straightforward to me, > > please let me know if there is anything where I could help. > > Following Adrian's comment, I prepated a patch that: > > * Renames *all* lincurl3* packages to libcurl4* (with Conflicts+Replaces) > * Removes the hacks for old SONAME and updates symbols (as Ondrej correctly > pointed out, the SONAME doesn't actually change as ww already ship a > "libcurl.so.4", but the lib symlinks and the symbols do) > * Makes the OpenSSL libcurl build against OpenSSL 1.1 > > I think this satisfies all the requirements for the OpenSSL migration, as well > as finally cleaning up the mess from the last botched transition as an added > bonus. > > Thoughts? > > The patch is at https://salsa.debian.org/debian/curl/merge_requests/2 > > Cheers > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature)
