[Pkg-postgresql-public] Dropping postgresql 8.3 for squeeze

[Dimitri Fontaine]

Dimitri Fontaine <dfontaine at hi-media.com> writes:
> Gerfried Fuchs <rhonda at deb.at> writes:
>>  Erm, you have said that way too often in this thread to not receive a
>> response for it: There is *no* editing needed for a testing-to-stable
>> migration; otherwise it wouldn't be a migration but a rebuild. There is
>> also *no* editing involved in unstable-to-testing migration. The package
>> is taken *as is*, there is no changes done to either the binary or the
>> source package.
>>
>>  I think you have a major misunderstanding here, or at least choose bad
>> wording that makes it sound that a migration of a package requires it to
>> get rebuilt.
>
> Then explain me with a right choice of words what I'm supposed to do for
> fixing the followings bugs, and why:

Ok, I'm mixing two things here that Gerfried thinks should not be mixed,
but I think in our context are the same one. Or at least it's how I
understand the situation after some breathing.

So, if you look at the debian infrastructure itself, it's right, no
building is required. That means that I have to edit the package, make a
new version of it, have it pushed on the debian machines then rebuilt,
and now it can be considered for migration, without rebuilding. Aha.

( The *only* reason I have to make a new version of my package is
  because of the way the debian project chooses to trust into stable
  those packages with no known EOL *more* than these packages with a
  known EOL that could be past the EOL of stable itself. )

So I'm saying that I have to edit my package for it to migrate, which
technically if you only look the debian side of things ain't true. But
if you only see the debian side of things, there's nothing to talk about
here, there's no problem, all is working fine.

Sadly, that's not the truth.

To be constructive, the patch I sent allows already to easily support
several PostgreSQL major versions in debian/rules and specify manually
which one you support. If you ask a build for a major version which is
not supported by debian, you get an error and skip the package.

What's missing is then a provided meta-package for build dependencies,
and a way to automatically generate a debian/config file with the right
entries there, probably a debhelper script like dh_pgxs.

When we have those elements, we can have a package source that
references all the extension's supported major versions and only
produces the binary packages for the one supported in the debian release
you target, or happen to build on.

For this to serve the goal of not having to edit the packages because
all of sudden a major version of PostgreSQL is now deprecated in next
stable version, we'll need to issue binNMU on existing source
packages. They get rebuild for only supported versions, and this new
build can migrate as-is. One intervention required, no extension
packagers has to work. Breathing.

Regards,
-- 
dim