On Sat, Jul 6, 2019 at 1:55 PM Jakub Jelinek <jakub@xxxxxxxxxx> wrote: > There is no way around having some compatibility version, either in the same > or other rpm, at least for a short period of time, because gcc needs libmpfr > and libmpfr needs to be built with gcc, so if you upgrade incompatibly > libmpfr, you will build that package, but once it is in the buildroots, gcc > will not install anymore and so nothing that needs gcc to build will > succeed building. Right. I think James's question was about submitting a package for review that is a different version of a package owned by somebody else. The maintainer of record for mpfr is Pavel Cahyna. I see he has an mpfr COPR: https://copr.fedorainfracloud.org/coprs/pcahyna/mpfr4/ but it looks like it hasn't been touched in a long time. This is what fedora-active-user has to say about him: Last login in FAS: pcahyna 2019-05-16 Last action on koji: Fri, 11 Aug 2017 package list entry revoked: zisofs-tools in f25 by pkgdb Last package update on bodhi: 2018-02-25 21:51:52 on package mpfr-3.1.6-1.fc27 Last actions performed according to fedmsg: - joerg.schilling@xxxxxxxxxxxxxxxxxxx updated nothing on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-07-04 08:29:55 () - ekanter@xxxxxxx updated nothing on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-07-04 08:06:42 () - rgm@xxxxxxxxxxxxxxx updated nothing on RHBZ#1583845 'Cannot write to CDrom at all' on 2019-06-27 10:22:24 () - joerg.schilling@xxxxxxxxxxxxxxxxxxx updated nothing on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-06-26 06:21:01 () - ekanter@xxxxxxx updated 'cc' on RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on 2019-06-26 06:02:22 () - pdupre@xxxxxxx updated 'cc' on RHBZ#1457252 'gnuplot-5.2.7 is available' on 2019-06-09 12:07:09 () - kevin@xxxxxxxxxxxxxxxx updated 'cc' on RHBZ#1583845 'Cannot write to CDrom at all' on 2019-06-05 14:27:05 () - kevin@xxxxxxxxxxxxxxxx updated 'cc' on RHBZ#1583845 'Cannot write to CDrom at all' on 2019-06-05 14:19:32 () - kevin@xxxxxxxxxxxxxxxx updated 'cc', 'dup_id', and 'resolution' on RHBZ#1580021 'wodim missing u+s will prevent usage at ...' on 2019-06-05 14:19:32 () - upstream-release-monitoring updated 'short_desc' on RHBZ#1457252 'gnuplot-5.2.7 is available' on 2019-05-29 01:05:26 () Last email on mailing list: ERROR:active-user:[Errno socket error] [Errno -2] Name or service not known Hmmm, what happened with the email on mailing list check? The current mpfr library (3.1.6) has soname "libmpfr.so.4". The new mpfr library (4.0.2) has soname "libmpfr.so.6". We want to keep both sonames available until all consumers can be switched to mpfr4, which may take awhile. We are not changing versions of libmpc, so the soname of "libmpc.so.3" is fixed. Therefore, we have to have the following packages, and their -devel subpackages, and it has to be possible to have them all installed in the same buildroot: - mpfr 3.1.6 - mpfr 4.0.2 - libmpc 1.1.0 linked with mpfr 3.1.6 - libmpc 1.1.0 linked with mpfr 4.0.2 I think it would be nice to have the "mpfr" package mean the latest version (i.e., 4.0.2), and introduce an mpfr3 package to hold 3.1.6. Likewise, it would be nice to have the "libmpc" package mean the version linked with mpfr 4.0.2, and introduce something, say "libmpc-mpfr3", to hold the version linked with mpfr 3.1.6. I can be swayed otherwise, but that would let us preserve package history, and we can hopefully drop the mpfr3 and libmpc-mpfr3 packages from the distribution someday. The tricky part, of course, is not breaking gcc while updating. Here is one way that could be accomplished. Caveat: I haven't actually tried doing this. If this seems reasonable, I would like to create a COPR and start doing these builds to make sure nothing breaks. - Alter the mpfr package to produce mpfr3, mpfr3-devel, mpfr, and mpfr-devel packages. The mpfr3 library has the old soname, the mpfr library has the new soname. The -devel packages must be installable in parallel, so the mpfr3 packages have libmpfr3.so*, /usr/include/mpfr3.h, and /usr/include/mpf2mpfr3.h. - Alter the libmpc package to produce libmpc and libmpc-mpfr3 packages. The libmpc package keeps the current soname. The libmpc-mpfr3 package gets the soname “libmpc-mpfr3.so.3”. Both are linked against mpfr3! That’s important! The -devel packages must be installable in parallel, so the libmpc-mpfr3 packages have libmpc-mpfr3.so* and /usr/include/mpc-mpfr3.h. - Build gcc with mpfr3 and libmpc-mpfr3. This means that gcc no longer depends on the mpfr and libmpc packages, so we can change them without breaking gcc. We will have to patch gcc to use the mpfr3 header file names and link with the altered library names. - Build libmpc again. Now libmpc-mpfr3 is linked with mpfr3 and libmpc is linked with mpfr. - Build gcc with mpfr and libmpc. We just drop the patch we used two steps ago and rebuild. Now gcc works with the new packages, and packages that use mpfr can be upgraded to mpfr4 at their leisure (but will FTBFS if they require mpfr 3, because of the altered header file and library names). Packages that use libmpc, however, are broken because libmpc is now linked with mpfr 4. Those packages must be moved to mpfr4 or built against libmpc-mpfr3. They are: o arm-none-eabi-gcc-cs o avr-gcc o cross-gcc o gap-pkg-float o ghdl o gnome-calculator o mingw-gcc o python-gmpy2 o sagemath I suggest this order for building packages. Each must be built against mpfr 4, or patched to continue building with mpfr 3. This order takes dependencies into account: - gawk (because it is in the default buildroot) - gdb (likewise) - All of these can be done in parallel: R-Rmpfr, arm-none-eabi-gcc-cs, avr-gcc, cross-gcc, fawkes, flint, gappa, genius, ghdl, gnome-calculator, gretl, ledger, libbytesize, libfplll, libqalculate, libscs, mingw-gcc, mpfi, ocaml-mlgmpidl, octave-interval, openscad, python-gmpy2, rasqal, sirocco - These can be done in parallel. Names in parentheses indicate dependencies: apron (ocaml-mlgmpidl), arb (flint), gap-pkg-float (mpfi), giac (mpfi), ocaml-tplib (ocaml-mlgmpidl), python-fpylll (libfplll), Singular (flint) - polymake (Singular), pynac (giac, Singular), why (apron) - sagemath (polymake, pynac) - texlive-base, just because it is a huge monster, so I want to deal with it last. It could probably be moved higher in this list. That is certainly not the only approach that can be taken. If somebody has a better idea, please share it. It is too late to attempt this for Fedora 31, but I would like to get the approach solidified and everything ready to go so this can land as early as possible in the Fedora 32 cycle. Regards, -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
