On 09/24/2011 08:24 AM, Mike Frysinger wrote:
On Friday, September 23, 2011 17:44:50 Nikos Chantziaras wrote:
I believe something needs to be done with the zlib-1.2.5.1-r1 and -r2
packages currently in the tree. The maintainer of zlib pushed those
revisions with a patch that alters macro identifiers, making Gentoo's
zlib incompatible with upstream.
the defines in question are internal to zlib. packages relying on them are
broken, plain and simple.
Then fix *them*, not zlib.
As a result, a lot of packages stopped building.
the *only* code that broke was code that was copied out of the zlib tree and
directly imported into other projects -- minizip. because the code was
designed to be compiled& linked as part of the zlib project, it uses internal
zlib defines. projects copying the code into their own tree and not cleaning
things up made a mistake.
for many, this is a direct violation of Gentoo policy and they should be fixed
to use the minizip code that zlib exports. for the rest that modify the code
heavily, they should stop using the internal defines since their own code base
doesn't support pre-ansi C compilers.
Then why did you "fix" zlib instead of those bad packages?
Bug reports for broken packages come in and then are being
modified to fit Gentoo's zlib.
and those fixes can be sent to the respective upstreams
See above.
Breaking compatibility with upstream zlib also means that non-portage
software, the ones I install with "./configure --prefix=$HOME/usr&&
make install", also won't build.
send the fix to the upstream maintainer
Maybe 5% of users know how to code. The rest doesn't.
It's a mess right now and it just doesn't look right. The bug that
deals with it was locked from public view:
because you keep presenting the same flawed ideas and ignore the responses.
in fact, all of the answers i posted above i already posted to the bug.
You ignore the suggestions, which is the reason the same arguments pop
up over and over again. The core issue is that ~arch is turning into a
testing ground for upstreams rather than for Gentoo packaging. It's not
nice to keep something in portage unmasked that is *known* to break
packages, and *especially* if it's a beta release of an important base
library (which zlib 1.2.5.1 certainly is). But you ignore that
repeatedly. And this makes it very frustrating to communicate.
~arch is not for cleaning up upstream crap. ~arch is for testing
packages that will later be marked stable.
