List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Friday, September 23, 2011 17:44:50 Nikos Chantziaras wrote:
> I believe something needs to be done with the zlib-18.104.22.168-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.
> 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.
> 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
> 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
> 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.
signature.asc (This is a digitally signed message part.)