Ignacio Vazquez-Abrams <ivazqueznet@xxxxxxxxx> 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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
