Bug 858894 - RFE: Update to latest upstream release 1.0
RFE: Update to latest upstream release 1.0
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libmpc (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Marek Polacek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-19 19:37 EDT by Paulo Andrade
Modified: 2013-10-29 10:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-29 10:16:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sage-libmpc.patch (2.44 KB, patch)
2012-10-27 12:42 EDT, Paulo Andrade
no flags Details | Diff

  None (edit)
Description Paulo Andrade 2012-09-19 19:37:24 EDT
libmpc library major update should not be a trivial task:
$ repoquery --whatrequires  'libmpc.so.2()(64bit)'
avr-gcc-0:4.6.3-2.fc18.x86_64
avr-gcc-c++-0:4.6.3-2.fc18.x86_64
cpp-0:4.7.1-8.fc19.x86_64
gcc-0:4.7.1-8.fc19.x86_64
gcc-alpha-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-arm-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-avr32-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-bfin-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-c++-0:4.7.1-8.fc19.x86_64
gcc-c6x-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-cris-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-frv-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-gfortran-0:4.7.1-8.fc19.x86_64
gcc-gnat-0:4.7.1-8.fc19.x86_64
gcc-go-0:4.7.1-8.fc19.x86_64
gcc-h8300-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-hppa64-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-ia64-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-java-0:4.7.1-8.fc19.x86_64
gcc-m32r-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-m68k-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-mips64-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-mn10300-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-objc-0:4.7.1-8.fc19.x86_64
gcc-objc++-0:4.7.1-8.fc19.x86_64
gcc-powerpc64-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-s390x-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-sh-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-sh64-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-sparc64-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-tile-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-x86_64-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
gcc-xtensa-linux-gnu-0:4.7.1-0.1.20120606.fc18.1.x86_64
libmpc-devel-0:0.9-3.fc18.2.x86_64
mingw32-cpp-0:4.7.1-3.fc18.x86_64
mingw32-gcc-0:4.7.1-3.fc18.x86_64
mingw32-gcc-c++-0:4.7.1-3.fc18.x86_64
mingw32-gcc-gfortran-0:4.7.1-3.fc18.x86_64
mingw32-gcc-objc-0:4.7.1-3.fc18.x86_64
mingw32-gcc-objc++-0:4.7.1-3.fc18.x86_64
mingw64-cpp-0:4.7.1-3.fc18.x86_64
mingw64-gcc-0:4.7.1-3.fc18.x86_64
mingw64-gcc-c++-0:4.7.1-3.fc18.x86_64
mingw64-gcc-gfortran-0:4.7.1-3.fc18.x86_64
mingw64-gcc-objc-0:4.7.1-3.fc18.x86_64
mingw64-gcc-objc++-0:4.7.1-3.fc18.x86_64
msp430-gcc-0:4.6.3-1.fc19.x86_64

I confess I am not familiar with the approach used by Fedora,
but since I need libmpc with major for a package I hope to make
a review request in the near future, I suggest creating a
libmpc-compat package, that obsoletes libmpc = 0.9. Once
everything that requires libmpc.so.2()* is rebuilt, it can
be disabled, and I suggest a build conditional for that, so
that it is easy to disable in a single line, or has enough
markup for a full removal later.

Spec URL: http://fedorapeople.org/~pcpa/libmpc.spec
SRPM URL: http://fedorapeople.org/~pcpa/libmpc-1.0-3.fc19.src.rpm
Comment 1 Petr Machata 2012-10-22 09:38:09 EDT
I don't really like the idea that we would ship libmpc-compat as a subpackage.  We should create a new package compat-libmpc.  I'm not sure whether to ship compat-libmpc-devel, my guess is that this shouldn't be necessary, but then again why not, chances are it will be necessary.
Comment 2 Thomas Spura 2012-10-22 09:43:31 EDT
I'd vote for a forward package aka "libmpc1", similar what we did for zeromq (which will stay at version 2 possibly forever) and a zeromq3 package for the 3.x.x version.

See bug #864937.

Compat packages are more for older versions of a package, as a library needing it cannot be ported and so on.
Comment 3 Petr Machata 2012-10-22 12:06:13 EDT
The two versions of libmpc are close to API-compatible (two functions were renamed).  I sincerely hope that we would only ship compat-libmpc for about a release, as mass rebuilds would naturally wean all the GCC's off libmpc<1.0.

(I expect that GCC builds with MPC 1.0, but I will check to make sure.)

I can name the package compat-libmpc or libmpc2, whatever the preference, but I would like to keep libmpc as the main MPC package.
Comment 4 Paulo Andrade 2012-10-22 13:37:20 EDT
I asked in the mpc-discuss mailing list about a simple reasoning of
the library major bump. If adding a identifier to the package name,
I suggest using the library major, not package name, as done by
other distros, but that would mean needing to have a
libmpc2 package to become orphan at some point, and a
libmpc3 package providing "libmpc".

I suggested generating it (and just a suggestion of naming it
libmpc-compat, what should matter is that it provides libmpc.so.2)
from the main libmpc package to cheat bureaucracy of creating a
new package that should become obsolete after next mass rebuild :-)
Comment 5 Petr Machata 2012-10-22 15:08:29 EDT
(In reply to comment #4)
> I asked in the mpc-discuss mailing list about a simple reasoning of
> the library major bump.

They removed two symbols.  They had to bump the soname.
Comment 6 Paulo Andrade 2012-10-22 16:31:44 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > I asked in the mpc-discuss mailing list about a simple reasoning of
> > the library major bump.
> 
> They removed two symbols.  They had to bump the soname.

This was a mandatory reason, and a compatibility layer (after all it
was symbols renamed) was not added because reaching version 1.0 looked
like a good checkpoint for cleanups as well.

This has a bad side effect of making updates in distros not trivial
as libmpc is linked to gcc, but is at least a good exercise on how to
handle these conditions :-)
Comment 7 Paulo Andrade 2012-10-27 12:42:57 EDT
Created attachment 634279 [details]
sage-libmpc.patch

I will use this patch in my work in progress sagemath package, so that symbols end up being resolved, and I did not find any issues with it.

This will allow the "current work in progress" sagemath package to be built in plain rawhide.
Comment 8 Fedora Admin XMLRPC Client 2013-09-11 07:32:30 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Paulo Andrade 2013-10-29 10:16:25 EDT
Already updated long ago.

Note You need to log in before you can comment on or make changes to this bug.