, and
the supported-version script that will only output the debian supported
ones, but will add to the list any version you have installed locally.
Regards,
--
Dimitri Fontaine
PostgreSQL DBA, Architecte
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
Roger Leigh rle...@codelibre.net writes:
I'll adopt whatever the consensus is once agreed upon in my
postgresql-debversion package. I can also put in conditionals
Good news, welcome aboard!
to make it build with older versions again, but I'd like a
pointer to an example to see what's needed
Roger Leigh rle...@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
Gerfried Fuchs rho...@deb.at writes:
If Python version changes, a binNMU is triggered on affected packages,
which is damn faster and more efficient than mass filling bug reports.
Without a line change to the modules sources.
I do not see why this is not doable for PostgreSQL.
In this case
Martin Pitt mp...@debian.org writes:
Dimitri Fontaine [2009-12-30 10:52 +0100]:
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.
That would be a major
Luk Claes l...@debian.org writes:
This would not work without rebuilding everything in testing which would
create a chicken and egg problem: we want to have everything tested and
build in unstable before migrating it to testing...
Ok. So what you want is automated-without-rebuild packages
Gerfried Fuchs rho...@deb.at writes:
Erm, the extensions need only to be available for the same set of
postgres versions we release. Why do we *need* to have the extensions
available for postgres versions we never released? If you don't mean
that, why would you upgrade the extensions then
Stephen Frost sfr...@snowman.net writes:
Nah, that's fine, someone else can and will maintain it properly if he's
not willing to. Of course, I'm curious as to just what extension this
is, since I might be that 'someone else'.
Well, I'll still be using them as debian packages, so hopefully you
Stephen Frost sfr...@snowman.net writes:
* Dimitri Fontaine (dfonta...@hi-media.com) wrote:
So ideally the extensions packaging should not have to be edited at all
and produce binaries for all supported PostgreSQL version. Supported by
the debian release which is building the package
Gerfried Fuchs rho...@deb.at writes:
that postgresql actually _is_ pretty unique here indeed.
Well, can you say that the kernel package currently in stable,
apparently 2.6.26, is still maintained by its upstream? I guess there's
a debian team able to maintain it independantly?
And it seems to
Hi, Martin Pitt mp...@debian.org writes: We currently have
PostgreSQL 8.3 and 8.4 in sid/testing. Just as in Lenny we only
want to support the latest major release in squeeze, and let the
postgresql-common architecture handle upgrades. With the freeze
being three months out, we should now
11 matches
Mail list logo
