Re: [Pkg-postgresql-public] Postgres major version support policy on Debian

Hi,

I enjoy discussing and I think we are getting closer to an understanding
with every mail.

Gerfried Fuchs wrote:
> It would have to flow from the main pool to backports. I am no
> authority here, even though I understand that it might sound a bit like
> it, but I don't see the chances for the exception in this case.

Okay. Looks like I'm rather trying to join the "official" packaging team
and bring Postgres 8.2 back alive on testing. We'll soon see how that
turns out.

> To have newer features within a small subgroup of packages. Take e.g.
> the pidgin package. It was updated several times with newer features but
> also changed interfaces. A backported package is per definition a moving
> target and not a static content, otherwise you won't ever be able to
> update it at all.

I think the main difference in understanding here is the updatability of
Postgres. I'm clearly thinking of Postgres 8.2 as a very different
package than Postgres 8.3.

We have more than one server where we are running *both* in parallel and
want to keep it that way. (Where "we" is Programmfabrik GmbH again). (In
fact even one where an additional 8.1 is running).

I think it's quite similar to python2.{3,4,5}.: sure one "can"
theoretically upgrade (with enough time and resources). But more often
enough one simply doesn't want to.

> No. Striving to not affect the high stability of the _base_ system is
> why it's done. While striving to have high stability for the packages
> within backports, it's core reason of existence is to *not* influence
> the base system unto which it's applied to.

I fail to see how that can be a reason for backports to exist. If your
main motivation is not to influence the base system, you certainly don't
need any backports.

Backporting always is a compromise between stability (of the old
software) and new features, IMO.

>> The front page continues to explain:
>>
>> "Backports are recompiled packages from testing (mostly) and unstable
>> (in a few cases only, e.g. security updates)"
>>
>> So there must already be other exceptions for good reasons.
>
> Yes. But pg 8.2 is neither in testing nor in unstable.

Agreed.

> Sorry to say so then but your wording was badly chosen in some parts. I
> don't deny that propably mine too, and given that we both seem to be
> German natives discussing this in English even sounds like fishing for
> even more problems here.

Yeah...

> I never really denied that. It's just that it wouldn't follow the
> current workflow that did hinder me to maintain it in the way it was
> before...

Understood.

I've been coming from another direction, thinking that adding Postgres
8.2 to only backports would be easier than adding it to Debian proper.
Maybe that's plain wrong. And Martin Pitt seems to be glad to get some
help...

> Because the way you worded your mails made it sound like you wanted to
> have some rules enforced that are out of the scope of the lists you post
> to.

Sorry if it sounded that way. I just wanted to know in what direction I
should go with Postgres 8.2 packages.

And yes, I must admit that I've been a bit disappointed by "suddenly"
(didn't read the backport-users...) missing Postgres 8.2 upgrades.

> I won't explain further here why I called that attitude arrogant, we
> can do that in private and propably in German to reduce the language
> barrier. And I'm glad to hear that you want to join the packaging team,
> thanks.

Cool.

> If you like and don't hold this discussion against me feel free to
> pester me with anything you like to. :)

Thanks for the offer. I'm trying keep the discussion on the topic and to
avoid personal offense.

>> Keeping to maintain all major Postgres versions in testing (and
>> unstable) would solve that issue as well.
>
> If we are able to work it out I'm all for doing so.

I'll try.

> No worries - and like hinted above, I'm also sorry for having sounded
> pretty strict, but I just wanted to point the things out properly
> instead of doing it like some others with a "no, won't work" reply. ;)

Hehe.. it certainly helped me better than than, yeah. Thanks for
productive criticism.

Regards

Markus Wanner