[Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze

Dimitri Fontaine dfontaine at hi-media.com
Wed Dec 30 13:17:58 UTC 2009


Roger Leigh <rleigh at codelibre.net> writes:
> On Wed, Dec 30, 2009 at 10:52:27AM +0100, Dimitri Fontaine wrote:
>> That's why I proposed having a single binary package for any extension,
>> embedding support for more than one major version of PostgreSQL. That
>> would match how the code is maintained.
>
> But is this true universally?

After seeing some of them, that would be my guess, yes.

>  Take my postgresql-debversion
> extension, for example.  In lenny-backports and squeeze, I
> supported building against both 8.3 and 8.4 (possibly earlier as
> well--untested).  For the new version now in unstable, I use
> 8.4-specific features which means it /won't build/ with 8.3 or
> earlier releases.

Generally what happens is that extension authors use #if to have a
single source compatible with several major version. Your way of
deprecating still maintained major versions is... unique, I think.

> You still need to know exactly which versions a given release
> of a given extension supports--it's not a given that it will
> support all versions.

Yes. There's no problem with having a debian/rules target that loops
over /usr/share/postgresql-common/supported-versions and filter out
those the extension does not support.

What I want to avoid is having to edit the package to drop support for
an upstream maintained release that you still can build and run just
fine in debian.

> While I think it might be possible to introduce a versionless
> extension package name, IMO this should only be a dependency-only
> package which installs the extension for the current server version
> (like postgresql-client et al).

That'd be fine if that'd allow for not editing the package source when a
major version of PostgreSQL is no longer supported in a debian release,
or when you want automated migration of an extension package from a
release to another, when their supported-versions are not the same.

> I have to confess, I'm still not entirely clear what the problem
> is here; when you install a new server version, the old extensions
> are still available; one just needs to install the equivalent set
> for the new server version prior to migrating data.  Is the lack
> of automation here the problem?

The problem for the maintainer is having to edit a package, hence do
some testing and QA again, when there's absolutely NO value in doing so,
neither for the maintainer, the extension or its users.

The problem for the user is that generally the extension is still
maintained for several (or all) current major versions. The user does
not want to be forced into a major-upgrade to benefit from minor-upgrade
bugfixes.

For example prefix-1.1.0 fixes a bug present in prefix 1.0.0. Both
versions build fine with PostgreSQL 8.1, 8.2, 8.3 and 8.4. Picture a
user running 8.3 in stable, and sid no longers have support for 8.3. It
that is the case when I offer prefix-1.1.0, then stable users will not
have it, because it only builds for 8.4, now. But that's only a debian
problem, there's no problem neither in prefix nor in PostgreSQL here.

Regards,
-- 
Dimitri Fontaine
PostgreSQL DBA, Architecte



More information about the Pkg-postgresql-public mailing list