--- Comment #7 from Michael Schwendt <bugs.michael(a)gmx.net> ---
All dependent packages will need to be rebuilt since this version
changes the version of the provided shared object:
libmpcdec.so.6()(64bit). The older was libmpcdec.so.5()(64bit)
Are they API compatible?
If they are not compatible, the typical solution is to create packages that
don't conflict with eachother.
$ rpmls -p musepack-libmpc-1.3.0-0.1.svn484.fc23.x86_64.rpm
I find the naming and subpackage split somewhat unfortunate.
The musepack-libmpc package does not contain a "libmpc". There hasn't
one before. libmpc is a common prefix for the project libs with MPC being an
abbreviation of Musepack. In SVN, libmpc is sort of an umbrella, with the
sub-projects stored in various subdirs.
There are only a couple of static libs built into the various tools. There is
no shared libmpcenc, for example. The old encoder was called "mppenc" as a tool
without a lib, too. The musepack-libmpc package contains only tools.
The musepack-libmpc-devel package doesn't contain any lib either, just
unversioned base headers. How much can you do with these headers only?
libmpcdec-devel needs them, but hey, everything is built from a single src.rpm,
so why create separate subpackages already? Would anything want only
And libmpcdec-devel cannot be used standalone, as it needs headers from
Finally, libmpcdec contains not only the single shared lib but also the
"mpcdec" command-line tool. It's at 1.0.0, however, not 1.3.0.
That's because the official release date is not reflected in the built rpms
except for the "r475" in %release. Upstream tells:
| Musepack SV8 libs & tools (r475)
| Stable release of Musepack SV8 libraries and tools
| License: BSD/GNU LGPL
| Release date: 2011.08.10
I don't know how important the r475 revision is for upstream when doing future
SVN trunk is at r485, but the internal version of libmpcdec is unchanged. It's
at 1.3.0 since 2009. The same rpm also builds the tools, each with an own
version. E.g. mpcenc is at 1.30.1, mpcdec at 1.0.0.
It would be difficult to specify a strict dependency on "libmpcdec > r484",
example, because one cannot ignore everything at the left side of Fedora's
%release value for that package.
Giving the tools package the internal version of libmpcdec is strange. Note
that a strict subpackage split could set an own %version for each subpackage,
Will the "Stream Version" ever change again? It's at SV8 for several years.
As a suggestion, I would name the Source RPM "musepack-sv8" (or simply
"musepack") and build subpackages in the same namespace:
musepack-sv8-libs <-- there's just one lib so far, however
musepack-sv8-tools <-- there's half a dozen tools
Easier to find for users searching for musepack. Currently, if you search for
"musepack", you would get musepack-libmpc not giving any hint that it contains
tools, and additionally, it pulls in libmpcdec as it doesn't work without that
If there ever will be more shared libs to put into individual subpackages, that
could still be done if necessary.
About the versioning here, it doesn't follow the guidelines.
As libmpc has been at 1.3.0 in 2009 already, this checkout cannot be a
pre-release of 1.3.0. No "0." prefix in %release. It would either need to be a
post-release snapshot, or a pre-release of whatever version would be released
next, e.g. 1.3.1 or 1.4.0.
Then the guidelines want the checkout date be inserted:
If the upstream release versioning scheme is unknown, %version could be set to
'0', which gives you much more freedom to squeeze details into %release.
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component