Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Nikos Chantziaras <realnc@...>
Subject: Re: zlib breakage
Date: Sat, 24 Sep 2011 05:03:56 +0300
On 09/24/2011 03:23 AM, Brian Harring wrote:
>> [...] Right now, zlib does the
>> exact opposite of what should be done; Vapier changed zlib, and tries to
>> fix the packages that break because of that change.  The correct way to
>> handle it is to let zlib be, and fix the packages that stopped working
>> with zlib
>> Why is that the correct way?  Because we don't know yet what upstream is
>> planning.  We don't know if they'll rename those macros.  If they won't,
>> then Gentoo is creating problems for itself.  Packages that won't build
>> out of the box on Gentoo's zlib will need to be patched.  And you can't
>> go to upstream of those packages with that patch, because it's none of
>> their business.  They know their code works against vanilla zlib, they
>> have no reason to change it.  If Gentoo decides to break a base library
>> by making it incompatible with the upstream version, it's their own fault.
> "Incompatible with upstream version" ?

Why in quotes?

> Quick bug count, 12 packages (most of which are doing bad things in
> their header usage) went boom.
> 13 out of *608* packages.  I reiterate, 6-!@#*ing-hundred-and-8.  If
> that 13 became 50 I'd be viewing this differently, but half the time
> core pkg upgrades break that /alone/ (meaning upstream induced
> breakage).

The packages that break with vanilla zlib (like Lynx, which I 
fixed myself and sent upstream) are less than those that break with r1 
and r2.  So that argument doesn't hold.  Also, you didn't rebuild the 
whole tree, so there's no way of knowing whether there's 13 packages 
that break or 130.

> The packages are broken; while vapier is mildly ahead of the curve,
> updating upstream is going in parallel.

If vapier is such an expert, why did he use _Z_ as the prefix for those 
macros?  It's a well known fact that identifiers beginning with an 
underscore and followed by a capital letter (or another underscore) are 
reserved in C and shouldn't be used.

> I strongly suspect you've got the unstated 13th, or hit some fallout
> thus why you're pushing on this as hard as you are.  While that sucks
> for you, you'd have hit the same breakage once upstream releases the
> API change.

Introducing something to the tree that is known to break packages means 
it's better to mask it.  On top of that, zlib is a beta version, 
which supports masking more strongly when you combine it with the breakage.

> All vapier is doing is frankly fixing the offending packages (which
> those patches then go upstream) so the upstream zlib change can be
> made w/out any fallout.

If upstream accepts the changes, then that's good work.  But not when 
doing that with an unmasked package.  ~arch is for testing.  We tested. 
  Now we know it's borked, so mask it.  When it looks ready, unmask it 
for another round of wide testing.

> By and large, this is good open source behaviour, and fits with the
> gentoo "don't fuck with upstream's releases" philosophy (which is
> aimed at avoiding the sort of hellacious backporting/monkey-patching
> debian/fedora are known for).

But we *did* fuck with upstream's release.

zlib breakage
-- Nikos Chantziaras
Re: zlib breakage
-- Matt Turner
Re: zlib breakage
-- Nikos Chantziaras
Re: Re: zlib breakage
-- Alec Warner
Re: zlib breakage
-- Nikos Chantziaras
Re: Re: zlib breakage
-- Brian Harring
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: zlib breakage
Next by thread:
Re: zlib breakage
Previous by date:
Re: Re: zlib breakage
Next by date:
GCC 4.6 unmasking

Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.