Re: [Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze
* Dimitri Fontaine <dfontaine@hi-media.com> [2009-12-30 14:17:58 CET]:
> Roger Leigh <rleigh@codelibre.net> writes:
> > On Wed, Dec 30, 2009 at 10:52:27AM +0100, Dimitri Fontaine wrote:
> > 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.
Why is it unique to use features only available in a later version?
That's the whole point of releasing newer versions, so they have newer
features that one would like to use. I rather would hope that it's
unique to *not* use newer features, implementing them wouldn't make much
sense then.
> 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.
This is the whole point of this thread: You won't be able to build and
run it just fine in Debian because the package won't be there anymore at
a certain point in time.
> 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.
It shouldn't be big of a deal to script something along that lines for
automation purposes. Actually, I started with something along that lines
for wesnoth. It creates the debian/* files from templates that contain
keyword replacement, including the filename (for your
debian/foo-8.3.install approaches).
> 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.
Several people have raised points that there actually _is_ value in it,
and that it is required in certain circumstances. Repeatedly claiming
otherwise won't get you anywhere.
> 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.
That's on a completely different area, and you know that. That's on the
area of wether the postgres maintenance team is willing to bear the
burden of shipping more than one major versions of postgres itself and
has nothing to do with the extensions (only indirect, but you can't run
an extension for a server that's not there, that's the point).
> 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.
The stable users will never have prefix-1.1.0 because that's a new
upstream version that won't get accepted into stable. If the bug fix is
relevant enough though it can and should be backported to the 1.0.0
version from stable where postgres 8.3 is available. There is no need to
have postgres 8.3 in unstable around for that.
Have fun!
Rhonda
Reply to: