On Thu, Mar 29, 2012 at 12:51 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Hitoshi Harada <umi.tanuki@gmail.com> writes:
>> Frankly I'm still against this patch. Since I started to review it
>> I've never been convinced with the use case. Yeah, someone said it'd
>> be useful to him, but as a developer of some of PGXN modules I don't
>> see it. I totally agree with Robert's point that one feature is not
>> standardized and nobody can tell how you can depend on the feature in
>> the end. Mind you, I've never heard about building dependency by its
>
> Ok, we might need to find another word for the concept here. Will think,
> would appreciate native speakers' thought.
>
>> name as a string in other packaging system. If you want to introduce
>> the concept of version dependency not feature name dependency, do
>> *it*; I don't think feature dependency solves it.
>
> I don't want to introduce version dependency, because I don't think we
> need it. If you want to compare what we're doing here with say debian
> packaging, then look at how they package libraries. The major version
> number is now part of the package name and you depend on that directly.
>
> So let's take the shortcut to directly depend on the “feature” name.
>
> For a PostgreSQL extension example, we could pick ip4r. That will soon
> include support for ipv6 (it's already done code wise, missing docs
> update). If you want to use ip4r for storing ipv6, you will simply
> require “ip6r” or whatever feature name is provided by the extension
> including it.
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.
Thanks,
--
Hitoshi Harada
