On ons, 2009-12-30 at 20:02 +0100, Martin Pitt wrote:
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
On sön, 2010-01-03 at 18:10 +0100, Markus Wanner wrote:
Peter Eisentraut wrote:
I guess the Python-packaging-like solution to that would be to always
support two PostgreSQL releases per stable Debian release.
I suspect that means one of them overlapping with oldstable, right?
yes
Just
On Wed, Dec 30, 2009 at 09:06:38PM +0100, Dimitri Fontaine wrote:
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
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
On Sat, Jan 02, 2010 at 09:18:35PM +0100, Dimitri Fontaine wrote:
Roger Leigh rle...@codelibre.net writes:
to make it build with older versions again, but I'd like a
pointer to an example to see what's needed to conditionally
build 8.4.
That depends a lot on what features of 8.4 you're
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? Take my
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.
But
* Dimitri Fontaine dfonta...@hi-media.com [2009-12-30 14:17:58 CET]:
Roger Leigh rle...@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
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
Hi,
Gerfried Fuchs wrote:
I see your point and don't object to it in principle. It's just that
manpower is lacking, including being able to do upstream work on the
packages when upstream cease their support on it.
Please note, that with Dimitri and me, there are already two people
offering
* Martin Pitt (mp...@debian.org) wrote:
Dimitri Fontaine [2009-12-30 14:17 +0100]:
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.
That's
Dimitri Fontaine [2009-12-30 14:17 +0100]:
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.
That's only true if the change is to drop a supported
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 regression wrt. upgrades, though, since an
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) wrote:
* Dimitri Fontaine dfonta...@hi-media.com [2009-12-28 12:14:25 CET]:
PS: I surely do not intend to fix my packages by desuporting 8.3, even
if that means they don't get into squeeze when it's labelled
stable. Having them hosted outside of debian will
* 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 and by the extension
itself, of course.
That's a
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
* Dimitri Fontaine dfonta...@hi-media.com [2009-12-28 16:22:40 CET]:
Stephen Frost sfr...@snowman.net writes:
I seriously doubt Debian would be able to properly maintain PG packages
after they've been EOL'd upstream.
So do I. I guess some other software ends up in debian stable and
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 and by
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
Dimitri Fontaine wrote:
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
24 matches
Mail list logo
