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 |