Re: Finer Extension dependencies - Mailing list pgsql-hackers

On Thu, Mar 29, 2012 at 4:37 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Hitoshi Harada <umi.tanuki@gmail.com> writes:
>> So my question is why you cannot depend on ip4r in that case.  If some
>> version of the module introduces ipv6, then let's depend on that
>> version.  It doesn't explain why a string feature name is needed.
>
> The only operator we have to compare version strings in PostgreSQL
> extensions is string equality. That's because we don't need more, and
> designing a version scheme policy would be far more work that any
> benefit I could imagine. And as we didn't enforce version naming policy
> in 9.1, it could be argued that it's too late, too.
>
> When you say 'require = ip6r' you are depending on *any* version of the
> extension that is providing it, whatever its version string. You don't
> have to know that '1.05' < '1.06' < '1.1' and you don't have to know
> that the first version with ipv6 support was called '1.06'.

If I recall previous discussion correctly, there's fairly broad
consensus among people Tom talks to that dependencies on specific
versions are inferior to dependencies on features provided by those
versions.  That having been said, it might be hard for package authors
to know what features other packages want to depend on; and perhaps
any version of a package might add a new feature that someone might
want.  So it might be that, after we add this feature, nearly all
packagers will do one of two things:

1. Not add a provides line at all, thus making it impossible for
anyone else to depend on specific versions; or

2. Add a new feature to the provides line with every release that does
anything other than fix bugs, leading to:

provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5,
foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-2.3,
foobar-3.0, foobar-3.1

If that turns out to be the case, we may regret designing the feature
this way.  Again, the fact that packaging is part of shipping a
PostgreSQL extension rather than something that gets tacked on after
the fact is not an irrelevant detail.  Red Hat can rearrange all the
tags they ship at will every time they put out a new version of their
distribution, they can enforce uniform standards for how those tags
are named, and, maybe most important of all, they don't need to add a
tag for every version of the feature that someone *might* want to
depend on - only the things that someone *does* want to depend on.

Now in spite of all that I'm not sure this is a bad way to go: maybe
trying to solve the problem and ending up with something imperfect is
better than throwing our hands up in the air and doing nothing.  But
on the other hand I don't think Harada-san's comments are entirely
ill-founded either: how sure are we that this is the right way to go,
and what feedback do we have from people who are using this feature
that leads us to think this is adequate?

Does anyone else have an opinion on this?  I think that technically
this patch can be polished well enough to commit in the time we have
available, but the question of whether it's the right design is
harder, and I don't want that to be my call alone.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company