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 F2C7F13877A for ; Thu, 26 Jun 2014 22:05:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3DBA0E08CE; Thu, 26 Jun 2014 22:05:08 +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 4A45AE0893 for ; Thu, 26 Jun 2014 22:05:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2DFB333FF91 for ; Thu, 26 Jun 2014 22:04:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5.5 tests=[AWL=-0.195, 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 hWZcOBxQRRQh for ; Thu, 26 Jun 2014 22:04:37 +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 CF33A33F852 for ; Thu, 26 Jun 2014 22:04:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X0HmU-0000U8-5L for gentoo-dev@gentoo.org; Fri, 27 Jun 2014 00:04:34 +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 ; Fri, 27 Jun 2014 00:04:34 +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 ; Fri, 27 Jun 2014 00:04:34 +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: Re: Changes in installed ebuilds Date: Fri, 27 Jun 2014 00:04:23 +0200 Message-ID: References: <1403570947.24976.1.camel@rook> <53A9E3EA.1050203@sumptuouscapital.com> <53A9EA70.8060207@gentoo.org> <20140626091328.425f7ec2@pomiot.lan> 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: 386e4c16-567e-42d4-adcd-5d18e3d4720f X-Archives-Hash: 50681cdcf907990191735226a59424f0 Michał Górny wrote: > Dnia 2014-06-26, o godz. 00:48:02 > Jörg Schaible napisał(a): > >> hasufell wrote: >> >> > Kristian Fiskerstrand: >> >> On 06/24/2014 09:25 PM, Jörg Schaible wrote: >> >>> 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. >> >> >> >> >> >> For what it is worth, I completely agree significant changes to stable >> >> ebuilds (hereunder changes to dependencies) should get a revision bump >> >> and go through normal stabilization procedures. >> >> >> >> >> > >> > That would be a waste of time and would increase the overall workload >> > on arch teams who already need 2-4 weeks to keep up with the queue. >> > There is no reason to re-stabilize a package after a build-time bug has >> > been fixed by adjusting the version of a dependency. >> > >> > Moreover, the fix that was applied was very important. >> >> >> And, since the official tree did not have an older version of those deps >> anyway, the upgrade in the stable dependent ebuilds was unnecessary. It >> just broke the tree for users with local or other overlays. > > But people could have older versions of those deps installed, and then > their systems would slowly become broken on upgrades. Since the issues > wouldn't be caught early properly, they would trigger incorrect > installs of another packages and a few dep-tree branches further, > an unexpected hard-to-debug failures. OK, you have a point. However, it is more dependent on the way people use emerge. This scenario could not have happen to me, I call emerge always with: emerge -uDvta --changed-use --with-bdeps=y Cheers, Jörg