The corosync and heartbeat packages are interpreting this guideline rather strictly:
http://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage
"Devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Usually, subpackages other than -devel should also require the base package using a fully versioned dependency."
In the case of those packages (and possibly others), these packages have -libs subpackages that contain only the shared libraries, but the -libs packages have hardcoded Requires: %{name} = %{version}-%{release}. This is causing unnecessary dependency bloat, and defeats the purpose of having a -libs subpackage. When asked about this behavior, the package maintainers point to this guideline.
Since I can't give away common sense, I'm forced to document this as an exception in the guidelines, hence I propose this addition to the aforementioned section:
"In the specific case of a %{name}-libs subpackage, which only contains shared libraries, that package does not need to explicitly depend on %{name} = %{version}-%{release} (unless there is some other technical reason, of course)."
Do they consider the -libs package to fall under the devel package clause or the other subpackages clause?
Tom, the full thread of the discussion on the corosync side is here:
https://lists.linux-foundation.org/pipermail/openais/2010-October/015245.html (thread starts here)
I am aware the same guys started another thread on the heartbeat package.
The reason why corosync-lib Requires: corosync (and I am fairly sure that heartbeat is in the same situation) is that the libraries itself require the daemon in order to work properly. There is no API in the library can be of any use without the daemon.
In most cases, for example mysql-lib, you can have an application that uses them, while the -server package is installed and accessible on another host. This is not true for corosync. The library needs the local daemon.
The root "problem" for the whole discussion is that pacemaker package/maintainer is kind enough to support 2 competitive cluster implementations (corosync and heartbeat). That means that installing pacemaker, who loves heartbeat get corosync packages installed, who loves corosync gets heartbeat installed too.
Both corosync and heartbeat can live together without problems installed on the same host. We made sure of that by coordinating with heartbeat maintainer (I can speak from the corosync/pacemaker side of the story).
My rationale for keeping it the way it is now is:
1) users will get a fully functional system out of the box (at the price of few MB to install both daemons but none of them run by default) 2) new users will not have to choose the core to use right away but swap at any time 3) users will not require to understand the whole packaging layout "install pacemaker get all" vs "install pacemaker but you need something extra but dunno what/which one".
Toshio: I consider -libs a subpackage. The libs-devel follows the devel package clause for obvious reasons.
FWIW, this explanation would count as "some other technical reason". The general case of -libs subpackages still holds true, and is worth clarifying in this case.
Instead of having -libs as an explicit exception can we not just make the text more general, something like:
Subpackages are often extensions for their basepackage and in that case they should require their base package. It is almost always better to over specify the version, so it's best practice to just use a fully versioned dependency: Requires: %{name} = %{version}-%{release}. Devel packages must require their base package using a fully versioned dependency.
This was approved. I'm taking for writeup.
Updated. Release announcement:
The Guideline that explains how and when to require base packages has been substantially revised. The old language focused on -devel packages and left other subpackages to the imagination of the reader. The update has more generic advice and uses -devel and -libs packages as examples.
Metadata Update from @toshio: - Issue assigned to toshio
Login to comment on this ticket.