1 |
On 09/24/2011 03:23 AM, Brian Harring wrote: |
2 |
>> [...] Right now, zlib does the |
3 |
>> exact opposite of what should be done; Vapier changed zlib, and tries to |
4 |
>> fix the packages that break because of that change. The correct way to |
5 |
>> handle it is to let zlib be, and fix the packages that stopped working |
6 |
>> with zlib 1.2.5.1. |
7 |
>> |
8 |
>> Why is that the correct way? Because we don't know yet what upstream is |
9 |
>> planning. We don't know if they'll rename those macros. If they won't, |
10 |
>> then Gentoo is creating problems for itself. Packages that won't build |
11 |
>> out of the box on Gentoo's zlib will need to be patched. And you can't |
12 |
>> go to upstream of those packages with that patch, because it's none of |
13 |
>> their business. They know their code works against vanilla zlib, they |
14 |
>> have no reason to change it. If Gentoo decides to break a base library |
15 |
>> by making it incompatible with the upstream version, it's their own fault. |
16 |
> |
17 |
> "Incompatible with upstream version" ? |
18 |
|
19 |
Why in quotes? |
20 |
|
21 |
|
22 |
> Quick bug count, 12 packages (most of which are doing bad things in |
23 |
> their header usage) went boom. |
24 |
> |
25 |
> 13 out of *608* packages. I reiterate, 6-!@#*ing-hundred-and-8. If |
26 |
> that 13 became 50 I'd be viewing this differently, but half the time |
27 |
> core pkg upgrades break that /alone/ (meaning upstream induced |
28 |
> breakage). |
29 |
|
30 |
The packages that break with vanilla zlib 1.2.5.1 (like Lynx, which I |
31 |
fixed myself and sent upstream) are less than those that break with r1 |
32 |
and r2. So that argument doesn't hold. Also, you didn't rebuild the |
33 |
whole tree, so there's no way of knowing whether there's 13 packages |
34 |
that break or 130. |
35 |
|
36 |
|
37 |
> The packages are broken; while vapier is mildly ahead of the curve, |
38 |
> updating upstream is going in parallel. |
39 |
|
40 |
If vapier is such an expert, why did he use _Z_ as the prefix for those |
41 |
macros? It's a well known fact that identifiers beginning with an |
42 |
underscore and followed by a capital letter (or another underscore) are |
43 |
reserved in C and shouldn't be used. |
44 |
|
45 |
|
46 |
> I strongly suspect you've got the unstated 13th, or hit some fallout |
47 |
> thus why you're pushing on this as hard as you are. While that sucks |
48 |
> for you, you'd have hit the same breakage once upstream releases the |
49 |
> API change. |
50 |
|
51 |
Introducing something to the tree that is known to break packages means |
52 |
it's better to mask it. On top of that, zlib 1.2.5.1 is a beta version, |
53 |
which supports masking more strongly when you combine it with the breakage. |
54 |
|
55 |
|
56 |
> All vapier is doing is frankly fixing the offending packages (which |
57 |
> those patches then go upstream) so the upstream zlib change can be |
58 |
> made w/out any fallout. |
59 |
|
60 |
If upstream accepts the changes, then that's good work. But not when |
61 |
doing that with an unmasked package. ~arch is for testing. We tested. |
62 |
Now we know it's borked, so mask it. When it looks ready, unmask it |
63 |
for another round of wide testing. |
64 |
|
65 |
|
66 |
> By and large, this is good open source behaviour, and fits with the |
67 |
> gentoo "don't fuck with upstream's releases" philosophy (which is |
68 |
> aimed at avoiding the sort of hellacious backporting/monkey-patching |
69 |
> debian/fedora are known for). |
70 |
|
71 |
But we *did* fuck with upstream's release. |