| 1 |
On Sat, Sep 24, 2011 at 02:58:02AM +0300, Nikos Chantziaras wrote: |
| 2 |
> On 09/24/2011 02:40 AM, Alec Warner wrote: |
| 3 |
> >> This was just another episode of Vapier's hostile and arrogant behavior |
| 4 |
> >> towards users. Every time someone comes up with a valid argument of why |
| 5 |
> >> he's wrong, the final answer is "don't care, I do what I please because I'm |
| 6 |
> >> the dev and you're not." So my reply was the politest I could come up with |
| 7 |
> >> without using the f-word. |
| 8 |
|
| 9 |
The problem with your justification here is the statement "he's |
| 10 |
wrong"; that's opinion (and in this realm the dev frankly 9 times out |
| 11 |
of 10 is more experienced in the pkg in question thus their opinion |
| 12 |
carries greater weight). Treating your opinion as justification to be |
| 13 |
an ass doesn't really fly, especially considering the stats I mention |
| 14 |
below. |
| 15 |
|
| 16 |
> > I'm curious what you think the final answer should be? |
| 17 |
> |
| 18 |
> Taking other people's input and concerns into account would be OK. |
| 19 |
> Knowing when you're wrong is a useful thing. Right now, zlib does the |
| 20 |
> exact opposite of what should be done; Vapier changed zlib, and tries to |
| 21 |
> fix the packages that break because of that change. The correct way to |
| 22 |
> handle it is to let zlib be, and fix the packages that stopped working |
| 23 |
> with zlib 1.2.5.1. |
| 24 |
> |
| 25 |
> Why is that the correct way? Because we don't know yet what upstream is |
| 26 |
> planning. We don't know if they'll rename those macros. If they won't, |
| 27 |
> then Gentoo is creating problems for itself. Packages that won't build |
| 28 |
> out of the box on Gentoo's zlib will need to be patched. And you can't |
| 29 |
> go to upstream of those packages with that patch, because it's none of |
| 30 |
> their business. They know their code works against vanilla zlib, they |
| 31 |
> have no reason to change it. If Gentoo decides to break a base library |
| 32 |
> by making it incompatible with the upstream version, it's their own fault. |
| 33 |
|
| 34 |
"Incompatible with upstream version" ? |
| 35 |
|
| 36 |
Quick bug count, 12 packages (most of which are doing bad things in |
| 37 |
their header usage) went boom. |
| 38 |
|
| 39 |
13 out of *608* packages. I reiterate, 6-!@#*ing-hundred-and-8. If |
| 40 |
that 13 became 50 I'd be viewing this differently, but half the time |
| 41 |
core pkg upgrades break that /alone/ (meaning upstream induced |
| 42 |
breakage). |
| 43 |
|
| 44 |
The packages are broken; while vapier is mildly ahead of the curve, |
| 45 |
updating upstream is going in parallel. |
| 46 |
|
| 47 |
I strongly suspect you've got the unstated 13th, or hit some fallout |
| 48 |
thus why you're pushing on this as hard as you are. While that sucks |
| 49 |
for you, you'd have hit the same breakage once upstream releases the |
| 50 |
API change. |
| 51 |
|
| 52 |
All vapier is doing is frankly fixing the offending packages (which |
| 53 |
those patches then go upstream) so the upstream zlib change can be |
| 54 |
made w/out any fallout. |
| 55 |
|
| 56 |
By and large, this is good open source behaviour, and fits with the |
| 57 |
gentoo "don't fuck with upstream's releases" philosophy (which is |
| 58 |
aimed at avoiding the sort of hellacious backporting/monkey-patching |
| 59 |
debian/fedora are known for). |
| 60 |
|
| 61 |
Nothing to see here, pretty much. |
| 62 |
~brian |
Archives