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 0CBC513877A for ; Fri, 1 Aug 2014 02:18:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8B48FE08FC; Fri, 1 Aug 2014 02:18:01 +0000 (UTC) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F195AE08FA for ; Fri, 1 Aug 2014 02:18:00 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id hy10so5664006vcb.4 for ; Thu, 31 Jul 2014 19:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=0eIrMf7EsAeR7xKgCddLsAjvOmu+X3cnJS5YpCHlRNU=; b=0CbBF9UP9T0IdFehbU/jxUx3u3JKMhJRENvGVFbW0UxrP12V/yszoiVRUFETSzZdND XkRgDKRORkOmkZdbY9uw4Au407h7+Kbw6nZWOjpL9PDJHWzHL+/l5aJXYMR2RgCUi9jy pUZrAJ7dvsmMxQ3rUxvjKHdlAfJZKQbhgDrN9jdgtDgpFG6ZKRkixYvIVhqdQSOqNg1w sy29tuOX/jaluCAKSp2ap3+tlayKj13yqIpUj/cjezLLtilrHeSuTW4DvmaHrIo2VVCF 2o1Nqw1bSIQFIOxi2FedTxfivWt4mw63gwzGqh3Q2vYwc62LCLTROGZzl26cVuT4CpXP wu/A== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.36.131 with SMTP id q3mr2328872vdj.90.1406859479878; Thu, 31 Jul 2014 19:17:59 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Thu, 31 Jul 2014 19:17:59 -0700 (PDT) In-Reply-To: <20140731211239.0eb282cb@pomiot.lan> References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> <20140731211239.0eb282cb@pomiot.lan> Date: Thu, 31 Jul 2014 22:17:59 -0400 X-Google-Sender-Auth: 761ziHLUKOL2CkrAgS1CUQ3KjjA Message-ID: Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 From: Rich Freeman To: gentoo-project@lists.gentoo.org Cc: Michael Palimaka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: d961e791-115b-4548-89cd-dabce50179aa X-Archives-Hash: d60f667d3e8412f37440c93964452e34 On Thu, Jul 31, 2014 at 3:12 PM, Micha=C5=82 G=C3=B3rny = wrote: > > Yes, exactly. We need to get dynamic-deps right if they are ever > supposed to become the default. That's one of the reasons that we want > to revert the problematic changes and make Portage use the default > model once again. Do we actually have some kind of list of issues with dynamic deps? The only specific one that I think I've seen is with prerm and subslot deps, but as was pointed out that issue actually is as much of a problem with static deps unless you unmerge all the reverse-deps before upgrading anything, followed by a re-merge. I have no problem with accepting that it is broken, but it would be nice to deal with more specifics and not with it in general. > > If you are really curious, I am working hard on providing tools to fix > the vdb inconsistencies caused by dynamic-deps. There were no specific > data because it wasn't available until today. > > My regularly updated desktop system (2-3 days between @world updates) > after disabling dynamic-deps has 77 packages needing rebuild. That > number includes a few virtuals, Perl packages and other low-effort > cases. And this is after the big, scary virtual/*udev changes. > > Over the next days I will obviously have more numbers. More > specifically, the number of packages needing rebuild after dependency > changes made by developers. It should be noted that the above number > includes one-time rebuild of packages that are simply ancient. > > There is a lot of FUD about unnecessary rebuilds. Sadly, most people > seem to fight a holy war against them without realizing the real > impact. In fact, more unnecessary rebuilds are caused by unnecessary > USE flags than by dependency changes. Yet the same people believe in > adding more flags to contain even more minor aspects of packages... Thank you for this. It is very helpful in gauging the likely impact of having more revbumps. One thing I don't want to do is create a barrier to anybody who wants to upgrade an eclass or do work on virtuals. I can just imagine endless debates about whether splitting a virtual is worth it since it will cause up to 250 rebuilds, etc. Is there any easy way to compare tree vs installed deps using the API? I have a script that is part of the way there, but I'm struggling to compare the vartree and porttree depdendencies (the portree dependencies need to be correctly reduced - if somebody has the list of function calls needed to reduce an RDEPEND from porttree to account for USE/etc in /etc/portage and substitute in subslots that would be helpful. code snippet: depstr =3D vartree.dbapi.aux_get(cpv, ["RDEPEND"])[0] depstr2 =3D porttree.dbapi.aux_get(cpv, ["RDEPEND"] )[0] flatdeps=3Dportage.dep.flatten(portage.dep.paren_reduce(depstr)) flatdeps2=3Dportage.dep.flatten(portage.dep.use_reduce(portage.dep.pare= n_reduce(depstr2))) Ideally those should be the same if static deps =3D dynamic deps, but I suspect it isn't appying the right USE flags (I'm not passing any), and it isn't substituting actual subslot values either. I'm also not sure if flatten is going to properly handle operators/etc. Rich