| 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. |
Archives