| 1 |
On 09/24/2011 02:40 AM, Alec Warner wrote: |
| 2 |
>> This was just another episode of Vapier's hostile and arrogant behavior |
| 3 |
>> towards users. Every time someone comes up with a valid argument of why |
| 4 |
>> he's wrong, the final answer is "don't care, I do what I please because I'm |
| 5 |
>> the dev and you're not." So my reply was the politest I could come up with |
| 6 |
>> without using the f-word. |
| 7 |
> |
| 8 |
> I'm curious what you think the final answer should be? |
| 9 |
|
| 10 |
Taking other people's input and concerns into account would be OK. |
| 11 |
Knowing when you're wrong is a useful thing. Right now, zlib does the |
| 12 |
exact opposite of what should be done; Vapier changed zlib, and tries to |
| 13 |
fix the packages that break because of that change. The correct way to |
| 14 |
handle it is to let zlib be, and fix the packages that stopped working |
| 15 |
with zlib 1.2.5.1. |
| 16 |
|
| 17 |
Why is that the correct way? Because we don't know yet what upstream is |
| 18 |
planning. We don't know if they'll rename those macros. If they won't, |
| 19 |
then Gentoo is creating problems for itself. Packages that won't build |
| 20 |
out of the box on Gentoo's zlib will need to be patched. And you can't |
| 21 |
go to upstream of those packages with that patch, because it's none of |
| 22 |
their business. They know their code works against vanilla zlib, they |
| 23 |
have no reason to change it. If Gentoo decides to break a base library |
| 24 |
by making it incompatible with the upstream version, it's their own fault. |
| 25 |
|
| 26 |
If, on the other hand, you send a patch upstream that fixes compilation |
| 27 |
against vanilla zlib 1.2.5.1, they will most probably accept it, because |
| 28 |
it's a fix for a problem that is not distro-specific. If their software |
| 29 |
won't build against zlib 1.2.5.1, it's *their* problem, not ours. |
| 30 |
|
| 31 |
This is why I think the current "solution" is headed 180 degrees from |
| 32 |
the correct direction. |
Archives