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 ED0341381F3 for ; Fri, 27 Sep 2013 22:27:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2ECD6E0DC2; Fri, 27 Sep 2013 22:27:04 +0000 (UTC) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F1870E0D69 for ; Fri, 27 Sep 2013 22:27:02 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id u57so3285124wes.37 for ; Fri, 27 Sep 2013 15:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nWE/yO0tuN3hXmuTsCAEhbhlKx49dDjvbPhAQLkgqDw=; b=q4VhlPeG7Da6h+FQ/dSn0xn2Daah05/cdLsa/vbS6XS4bfbZEF0mU6jmOF5QRItI4c LEQhHUzcRjCXzr8nZkozMzs7l43Cy+syBIutPPFossGRkzDKcHG7GVgPyjIzyHER4uSN r950WFkmb3IVoCLwuWPX5x58yEsobETY4HNU7y8kyTdB2Gnr6dabQ5OTDdjWRvz3eWcU Yjbr1AZg0l4VGOAeee4/Y0NtQpRTOnUUVB72wyK+7oz2FW9bxl0IFZ9mWh+e2FzX/78v szZvazrx0Kp5gHTerittsYzZF/fDKiTiC0GqykfuGz1SxUs0ei2NyoaoMC02xrPf06it GO9Q== X-Received: by 10.180.91.16 with SMTP id ca16mr4334459wib.57.1380320821409; Fri, 27 Sep 2013 15:27:01 -0700 (PDT) Received: from [172.20.0.41] (196-210-126-33.dynamic.isadsl.co.za. [196.210.126.33]) by mx.google.com with ESMTPSA id mw9sm208307wib.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 15:27:00 -0700 (PDT) Message-ID: <52460528.30303@gmail.com> Date: Sat, 28 Sep 2013 00:22:32 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Q on portage's rational to re-emerge packages References: <1380270284.4038.0@numa-i.igpm.rwth-aachen.de> <52454B37.2050202@gmail.com> <1380274123.4038.1@numa-i.igpm.rwth-aachen.de> <20130927104321.GC3105@TranscendTheRubicon.fritz.box> <20130927111808.GA875@ca.inter.net> In-Reply-To: <20130927111808.GA875@ca.inter.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 51bfe87a-3376-47d2-bf9d-f3865e942dbf X-Archives-Hash: 0ffeb0cefff6100d6be0eba3806e530a On 27/09/2013 13:18, Philip Webb wrote: > 130927 Hinnerk van Bruinehsen wrote: >> you are encountering a relatively new feature of portage >> that is supposed to make revdep-rebuild & emerge @preserve-rebuild obsolete. >> The logic is, that if you update a package, other packages >> depending on this package will automatically rebuild to prevent breakage. >> It seems that in your case portage "thinks" that one of that packages >> depends on zsh-completion and pulls that in for rebuild, >> which in turn, most likely via setuptools or PyQt4, >> pulls libreoffice to rebuild. > > I have found sometimes that Portage wants to remerge LO or similar, > but in fact the existing installed version continues to work regardless. > Try remerging the other pkgs first & see if LO still functions as usual ; > only if it doesn't do you need to remerge it. Also consider how portage "knows" to rebuild something. In truth, it doesn't know and has no way to just find out. It has to rely on data added to the ebuild, and that's where this new feature called sub-slots comes in. In a nutshell, it's a DEPEND in reverse. LO has this one for example: =dev-util/mdds-0.8*:= That's a classic DEPEND, to install LO you must have mdds, so it gets pulled in and built. From then on portage keeps mdds up to date and knows it must use only version 0.8.something. So far so goo. But what happens if mdds-0.8.1 introduces an API/ABI change that breaks LO? Traditionally we had no way of dealing with this in ebuilds and had to rely on revdep-rebuild and @preserved-rebuild, both of which are ugly hacks (never mind that they work reliably). Portage still had no way of knowing breakage would happen if it did it's usual thing, so that's where subslots come in (the := notation)[1] Basically, it say something like "LO DEPENDS on mdds, but also if the installed version of mdds later changes, then LO needs to be rebuilt to properly link against the new (and changed) version of mdds. This only works right if the ebuild maintainer is on the ball, watches Changelogs for the DEPENDS packages and put the proper metadata in the ebuild. You can imagine how this can work out very very well when done right, and if the maintainer makes a mistake (or doesn't clearly understand how it works) it can cause many unneccessary rebuilds (but not actually *break* stuff). Huge packages like LO with many interconnected DEPENDS are always going to be the usual victim I'm afraid... And then there's things that use poppler, boost, PyQT and pykde4 - a similar effect is at work. End result = your cpus will be kept nice and toasty warm doing lots of compiles but actual breakage of the sort that led to revdep-rebuild being developed should reduce dramatically. Some unneccessary rebuilds are the price we pay for not having breakage. In Helmut's specific case here, the cause seems to be python-exec. I missed that one myself somehow so had no idea it was hanging around biting folks. [1] For clarity, I'll leave out explaining syntax here, that is documented elsewhere. -- Alan McKinnon alan.mckinnon@gmail.com