[Fedora-packaging] Policy question: how tight should cross-subpackage Requires be?

[Tom Lane]

Is there, or should there be, any Fedora packaging policy about the
following question?  (I see nothing in the Guidelines at the moment.)

Given a single SRPM generating multiple sub-RPMs, some of which depend
on each other, how hard should the maintainer try to ensure that
matching versions of the sub-RPMs are installed?  Possible answers
include:

1. Do nothing, rely on automatically generated requires (eg, the major
version of a shared library's soname).  Maximum flexibility, maximum
possibility of allowing installations that don't actually work.

2. Put in cross-package requires of the form
	Requires: %{name}-libs = %{version}
ie, constrain to "same upstream version"

3. Put in cross-package requires of the form
	Requires: %{name}-libs = %{version}-%{release}
ie, constrain to "exact same build"

Currently, I have some packages that do #2 and some that do #3,
and I have an open bug suggesting that #3 is the way to go because
it ensures yum will update all installed subpackages together:
https://bugzilla.redhat.com/show_bug.cgi?id=444271

However this idea was questioned on an upstream mailing list
on the grounds that users shouldn't be forced to update all
subpackages together.

I've got mixed feelings about it myself.  I see the point about
not constraining users unnecessarily, but there is no way that
anyone is ever going to have done any testing on mix-and-match
installations --- certainly I haven't got time to.  (As an example
of possible problems, different %{release} builds might have used
different configure options, leading to builds that really are
incompatible.)  I think I'd rather ship RPMs that try to enforce
that only tested combinations are installed.  There's always
--nodeps for those who think they're smarter than me...

So, first, has anyone got an opinion about this, and second,
should a policy recommendation be enshrined?

			regards, tom lane