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
