List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On 09/24/2011 02:40 AM, Alec Warner wrote:
>> This was just another episode of Vapier's hostile and arrogant behavior
>> towards users. Every time someone comes up with a valid argument of why
>> he's wrong, the final answer is "don't care, I do what I please because I'm
>> the dev and you're not." So my reply was the politest I could come up with
>> without using the f-word.
> I'm curious what you think the final answer should be?
Taking other people's input and concerns into account would be OK.
Knowing when you're wrong is a useful thing. Right now, zlib does the
exact opposite of what should be done; Vapier changed zlib, and tries to
fix the packages that break because of that change. The correct way to
handle it is to let zlib be, and fix the packages that stopped working
with zlib 18.104.22.168.
Why is that the correct way? Because we don't know yet what upstream is
planning. We don't know if they'll rename those macros. If they won't,
then Gentoo is creating problems for itself. Packages that won't build
out of the box on Gentoo's zlib will need to be patched. And you can't
go to upstream of those packages with that patch, because it's none of
their business. They know their code works against vanilla zlib, they
have no reason to change it. If Gentoo decides to break a base library
by making it incompatible with the upstream version, it's their own fault.
If, on the other hand, you send a patch upstream that fixes compilation
against vanilla zlib 22.214.171.124, they will most probably accept it, because
it's a fix for a problem that is not distro-specific. If their software
won't build against zlib 126.96.36.199, it's *their* problem, not ours.
This is why I think the current "solution" is headed 180 degrees from
the correct direction.