Robert Haas <robertmh...@gmail.com> writes: > On Mon, Apr 4, 2011 at 5:48 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers