On Sat, 2019-07-06 at 17:58 -0600, Jerry James wrote: > 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 That seems appropriate. We need to discuss this with pcahyna. I have CCd him. Pavel, please see above. To avoid this issue in the future, is it possible to have the two separate packages maintained by separate teams, or is that just a headache waiting to happen? James. -- James Paul Turner University of Sussex Arpra: Arbitrary-Precision Range Analysis https://github.com/arpra-project/arpra _______________________________________________ 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
