Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Apr 4, 2011 at 5:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> ... In particular I'm really skeptical of the theory that we need
>> or should want version restrictions in Requires references. �The
>> equivalent feature in RPM is deprecated for Fedora/RedHat packaging use,
>> and I see no reason why we'd need it more than they do.
> Oh, really? How can you possibly get by without it? Dependencies of
> this type are all over the place.
Yeah, but the proposed solution doesn't actually fix the problem.
There are various issues, but the fundamental objection is that when you
really need it the information is usually wrong/obsolete, especially if
it's maintained by hand. As an example, if we have foo depending on
bar and it says "Requires: bar >= 2.0", that's all well and good, but
it tells us nothing whatsoever about whether this version of foo will
work with bar 3.0, especially if 3.0 postdates the time when the foo
author put that into his specfile. Maybe we should really interpret
that as "Requires: bar >= 2.0 && < 3.0", or maybe not. It's also very
easy for foo's author to start using some nice_bar_function() without
realizing that that was actually only added in bar 2.1.
If you want automatic dependency checking to actually do something
useful, you need something very substantially finer-grained and more
complex than this. In the Fedora world they're mostly depending on
per-shared-library sonames and per-exported-symbol symbol versioning,
and even then it doesn't always do what you wished. But I'll note
that neither of those mechanisms bothers to infer any version ordering:
either you have a match, or you don't.
The equivalent thing of what's now considered good packaging practice
would probably be to extract lists of specific objects provided or
required by a module, preferably automatically. The requires side of
that might be doable just by inspecting pg_depend. The provides side
would be harder, mainly because you'd want some way to omit objects
that are considered purely internal to a module.
Anyway, I'm uneager to adopt a practice that was discredited years ago
among real packaging systems. I think it'll just delay somebody
deciding to fix it properly.
regards, tom lane
