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. > 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. -mike
signature.asc
Description: This is a digitally signed message part.
