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
>
Hi,
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?
Just wondering: does the python project have any kind of support
pr
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.
>
> T
On Sat, Jan 02, 2010 at 09:18:35PM +0100, Dimitri Fontaine wrote:
> Roger Leigh 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 specificall
Roger Leigh 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 to conditionally
On Wed, Dec 30, 2009 at 09:06:38PM +0100, Dimitri Fontaine wrote:
> Martin Pitt 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
> >> wou
Martin Pitt 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 regression wrt.
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
up
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 support
* 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.
>
>
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
Gerfried Fuchs 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 y
* Dimitri Fontaine [2009-12-30 15:05:37 CET]:
> Gerfried Fuchs writes:
> > 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.
>
> The point of this thread is to *change*
* Dimitri Fontaine [2009-12-30 14:17:58 CET]:
> Roger Leigh 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 earl
Roger Leigh 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 tru
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 postg
Martin Pitt writes:
> I think what you have in mind is already there. Calling
> /usr/share/postgresql-common/supported-versions will print out a list
> of major versions which are supported on the current release
> (Debian/Ubuntu). I maintain that to provide correct debconf obsoletion
> messages o
Dimitri Fontaine [2009-12-28 16:22 +0100]:
> I proposed a solution and I'm willing to spend effort on it, as soon as
> Martin Pitt says it's something he wants to see happen.
>
>
> http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2009-December/000490.html
I think what you have in
Gerfried Fuchs 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
> me that (
Stephen Frost 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 the extension
* Dimitri Fontaine [2009-12-28 16:22:40 CET]:
> Stephen Frost 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
> reaches EOL before debian stable does,
Stephen Frost 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 will
just have
Gerfried Fuchs 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 when you don'
* 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
* Gerfried Fuchs (rho...@deb.at) wrote:
> * Dimitri Fontaine [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 be less work and
Luk Claes 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 migration
from un
* Dimitri Fontaine [2009-12-28 12:14:25 CET]:
> This might look strange for the debian project itself but please
> consider that switching a production server from stable to next stable
> seldom means upgrading PostgreSQL alongside. So we *need* to have the
> extensions available for old-major som
Dimitri Fontaine wrote:
> Hi, Martin Pitt 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 o
Hi, Martin Pitt 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 start to cle
29 matches
Mail list logo
