Red Hat Bugzilla – Bug 858894
RFE: Update to latest upstream release 1.0
Last modified: 2013-10-29 10:16:25 EDT
libmpc library major update should not be a trivial task:
$ repoquery --whatrequires 'libmpc.so.2()(64bit)'
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
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.
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.
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.
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 :-)
(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.
(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 :-)
Created attachment 634279 [details]
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Already updated long ago.