ed by the extension sources, 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
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
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
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
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 m
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
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
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'
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
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
12 matches
Mail list logo
