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

[Tom Lane]

Ignacio Vazquez-Abrams <ivazqueznet at gmail.com> writes:
> On Mon, 2008-05-05 at 12:40 -0400, Tom Lane wrote:
>> 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.

> Show me a package that would break if a different version library was
> used that has the same soname and I'll show you a developer that needs
> to learn how to properly use sonames.

Hmm, you think a version digit or so is enough to encode everything
there is to be known about a package?

I'm using a fairly wide definition of "break" here, such as package A
not having an optional capability that package B expects it to have ---
in the context of the stuff I work with, a good example would be SSL
support in a client library.  A non-SSL-capable client could fail to
interoperate with a server that was configured to demand SSL protection,
or vice versa.  And that would have nothing to do with whether the
client library could successfully link with its calling application,
which is the sum total of what the soname is expected to handle.
The soname convention simply hasn't got the bandwidth to handle every
possible combination of build options that a given upstream tarball
might support.

In places where it really matters, we have developed conventions for
Requires: symbols that can convey fine detail, for instance
	BuildRequires: perl(ExtUtils::Embed)
But I can't see going to that much trouble for intramural dependencies
among the subpackages of a single SRPM.

			regards, tom lane