Re: Extensions Dependency Checking

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions Dependency Checking
Date: 2011-04-05 20:42:16
Message-ID: BANLkTimn1z31QqOgV-fRi89j0atYpL+k7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 5, 2011 at 4:20 PM, David E. Wheeler <david(at)kineticode(dot)com> wrote:
> On Apr 4, 2011, at 3:57 PM, Tom Lane wrote:
>
>>> I think the general movement is toward *feature* dependancies.  So for
>>> intstance, an extension can specify what *feature* it requires, and
>>> difference "versions" of an extension can provide different
>>> "features".
>>
>> Right.
>
> Sounds like a book-keeping nightmare for extension developers. It will discourage large or rapidly-evolving extensions like pgTAP because it will be a PITA to specify features.

Sure, but if you want, the "feature" you can provide can be something like:
pgtap-1.0 (or any of pgtap-0.2{0,1,2,3,4}).

And if your package is backwards compatable, it could even provide:
pgtap-0.25
pgtap-0.24
pgtap-0.23

And that also means that you don't have to screw every body over when
some future pgtap-123.45 is no longer compatible, and the extensions
have relied on "$VERSION > 0.23" meaning they'll work with it.

I mean, PG itself is an example. Does pg > 8.4 mean your code will
work with all future (or even past, but > 8.4) PG versions?

>> We're not there yet, and we're not going to get there in time for 9.1.
>> But in any case, mechanisms that involve version ordering comparisons
>> seem to be on their way out for deciding whether package A is
>> compatible with package B.
>
> This is news to me, frankly, and the bookkeeping requirements seem potentially awful.
>
> If it's possible that it won't work out this way, that those arguing for version dependency resolution end up getting the consensus, not having a version string format is going to be a nightmare. On the other hand, if we added one now, and feature dependency tracking won the day, well, a version string format could always be loosened later.

As someone who has had to try and deal with "package versions" for
dependencies in RPM and DEB, and been through the hell that is open
source package variants, all with the ability to turn on/off features
at configure/compile time, a just versions even with <, <=, =, >=, >
all mapped correctly isn't good enough.

Of course, I'ld love for extension in 9.1 to provide a basic
provides/features for my extension to give, but if that train has
already left the station, I don't have much choice ;-(

a.

--
Aidan Van Dyk                                             Create like a god,
aidan(at)highrise(dot)ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-04-05 20:47:40 Re: WIP: Allow SQL-language functions to reference parameters by parameter name
Previous Message David E. Wheeler 2011-04-05 20:20:36 Re: Extensions Dependency Checking