From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 8ACED13877A for ; Wed, 25 Jun 2014 22:50:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C8FA3E0964; Wed, 25 Jun 2014 22:50:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E3F66E090A for ; Wed, 25 Jun 2014 22:50:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 4209A33FA4D for ; Wed, 25 Jun 2014 22:50:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5.5 tests=[AWL=-0.209, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gN6EI4wR6nFH for ; Wed, 25 Jun 2014 22:50:08 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 5F04C33F616 for ; Wed, 25 Jun 2014 22:50:06 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wzw0x-0004C7-RX for gentoo-dev@gentoo.org; Thu, 26 Jun 2014 00:50:03 +0200 Received: from hsi-kbw-109-192-107-076.hsi6.kabel-badenwuerttemberg.de ([109.192.107.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jun 2014 00:50:03 +0200 Received: from joerg.schaible by hsi-kbw-109-192-107-076.hsi6.kabel-badenwuerttemberg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Jun 2014 00:50:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: =?UTF-8?B?SsO2cmc=?= Schaible Subject: [gentoo-dev] Re: Re: Changes in installed ebuilds Date: Thu, 26 Jun 2014 00:46:07 +0200 Message-ID: References: <1403570947.24976.1.camel@rook> <53A9ED2D.70002@gentoo.org> 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" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: hsi-kbw-109-192-107-076.hsi6.kabel-badenwuerttemberg.de User-Agent: KNode/4.12.5 X-Archives-Salt: 834653d4-cf48-460a-b876-a60587f63da3 X-Archives-Hash: 4bc718f7ea7aa0d39341746334fcb287 hasufell wrote: > Jörg Schaible: >> Alexandre Rostovtsev wrote: >> >>> On Mon, 2014-06-23 at 22:15 +0200, Jörg Schaible wrote: >>>> So, why the heck, was the dependency to dev-libs/glib changed for an >>>> existing ebuild without increasing its version (e.g. >>>> dbus-glib-0.100.2-r2)? >>> >>> Please see http://article.gmane.org/gmane.linux.gentoo.devel/91615 >> >> These blocks had nothing to do with the multilibs ABI. It has been just >> the updated versions for the dependencies. >> > > I'm not sure if you understood the bug. It was breaking dependency > calculation of portage, so the fallout you see is minor to what was > going on. The dependency calculation worked perfectly, it just could not resolve them anymore, because those suddenly required newer packages are hard masked on my system to keep the software *I* need for my daily work running. > Revbumping and restabilizing all of these packages (a LOT) would have > been unrealistic. And the question was, why was the version for these deps upgraded in those ebuild at all. The official tree did not contain anything older anyway. > Another possibility would have been to revbump the ebuild and make it > instantly stable without arch teams involvement. That would actually be > the cleaner way, but afair some people don't agree with that, so it > isn't standard practice. > > However, you can still overwrite tree ebuilds in your local overlay and > revert dependencies. I once did that with pypy, because it triggered too > many rebuilds for me. That's what I did in the end for all "bumped" ebuilds, but the effort would not have been necessary at all. - Jörg