Re: Finer Extension dependencies

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> 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
>>
>> This is what I have expected to do. In new releases of pgTAP, I’d probably
>> just add version lines. I might give certain releases names, but probably
>> not. I’m too lazy, and if a given release has more than one new feature,
>> it’d be a bit silly.
>>
>> I’ve never been very keen on this approach, but then I don’t understand
>> packaging systems very well, so it might rock, and I just don’t know how
>> to use it properly. But I cannot tell.
>
> So the idea is that you're actually supposed to separately catalog
> each feature you added (e.g. each new function), so that people can
> depend specifically on those features. Then if you remove the
> function again in some distant future, you stop advertising that
> feature (but you can still advertise any other features you added in
> the same release). If you're not going to do that, then this feature
> as proposed is strictly worse than figuring out a way to compare
> version numbers, because it's more work, some people will not bother
> to update the provides line, and other people will sometimes forget
> it.
>
> I don't really have the foggiest idea how people using other packaging
> systems handle this. It seems like it would be a huge pain in the
> rear end to be continually adding Provides: lines to RPMs for every
> new feature that a new version of a package offers, not to mention
> that you'd hardly want the corresponding Requires: lines to have to
> enumerate all the public interfaces those packages used just in case
> one of them ever went away. I have a feeling I'm missing part of the
> picture here, somehow.

Basically those examples are far too fine grained. Let's get back to the
example of ip4r that I know better. I would imagine those provides lines
in there:

provides = ip4, ip4r
provides = ip4, ip4r, ip4r_gist, ip4r_gin

Then when adding ipv6 support and datatypes:

provides = ip4, ip4r, ip6, ip6r
provides = ip4, ip4r, ip6, ip6r, ip4r_gist, ip4r_gin, ip6r_gist, ip6r_gin

Pick any one as what I would consider a realistic example.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support