From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R7FeR-0006DD-2R for garchives@archives.gentoo.org; Fri, 23 Sep 2011 23:59:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 43B1321C18A; Fri, 23 Sep 2011 23:59:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 110E821C028 for ; Fri, 23 Sep 2011 23:58:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 978771B4040 for ; Fri, 23 Sep 2011 23:58:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 required=5.5 tests=[AWL=1.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcK-XEMdTL01 for ; Fri, 23 Sep 2011 23:58:33 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id C1F0C1B402F for ; Fri, 23 Sep 2011 23:58:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R7FdR-0006gs-Lc for gentoo-dev@gentoo.org; Sat, 24 Sep 2011 01:58:25 +0200 Received: from athedsl-373981.home.otenet.gr ([79.131.12.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Sep 2011 01:58:25 +0200 Received: from realnc by athedsl-373981.home.otenet.gr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Sep 2011 01:58:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Nikos Chantziaras Subject: [gentoo-dev] Re: zlib breakage Date: Sat, 24 Sep 2011 02:58:02 +0300 Organization: Lucas Barks Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: athedsl-373981.home.otenet.gr User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110920 Thunderbird/6.0 In-Reply-To: X-Archives-Salt: X-Archives-Hash: 66252784140d46b3e1823536054a5295 On 09/24/2011 02:40 AM, Alec Warner wrote: >> This was just another episode of Vapier's hostile and arrogant behavior >> towards users. Every time someone comes up with a valid argument of why >> he's wrong, the final answer is "don't care, I do what I please because I'm >> the dev and you're not." So my reply was the politest I could come up with >> without using the f-word. > > I'm curious what you think the final answer should be? Taking other people's input and concerns into account would be OK. Knowing when you're wrong is a useful thing. 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 1.2.5.1. 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. If, on the other hand, you send a patch upstream that fixes compilation against vanilla zlib 1.2.5.1, they will most probably accept it, because it's a fix for a problem that is not distro-specific. If their software won't build against zlib 1.2.5.1, it's *their* problem, not ours. This is why I think the current "solution" is headed 180 degrees from the correct direction.