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 DADDA13877A for ; Fri, 1 Aug 2014 19:41:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B891DE0960; Fri, 1 Aug 2014 19:41: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 17AF8E0928 for ; Fri, 1 Aug 2014 19:41:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 185A43401CB for ; Fri, 1 Aug 2014 19:41:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.282 X-Spam-Level: X-Spam-Status: No, score=-1.282 tagged_above=-999 required=5.5 tests=[AWL=0.088, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ruXOZ4kg_eNB for ; Fri, 1 Aug 2014 19:41: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 9F40A3401AA for ; Fri, 1 Aug 2014 19:41:06 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XDIhI-0001t4-KC for gentoo-project@gentoo.org; Fri, 01 Aug 2014 21:41:00 +0200 Received: from ppp118-209-168-229.lns20.mel6.internode.on.net ([118.209.168.229]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2014 21:41:00 +0200 Received: from kensington by ppp118-209-168-229.lns20.mel6.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Aug 2014 21:41:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-project@lists.gentoo.org From: Michael Palimaka Subject: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 Date: Sat, 02 Aug 2014 05:40:47 +1000 Message-ID: References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> <20140731211239.0eb282cb@pomiot.lan> 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 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ppp118-209-168-229.lns20.mel6.internode.on.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <20140731211239.0eb282cb@pomiot.lan> X-Archives-Salt: ce64ed26-e5b9-4866-9b20-3430881c101f X-Archives-Hash: ada6ad02d40a4e7e3ad41379f960b0a8 Thanks for taking the time to compose a reply that actually has some substance - you're the only person involved with Portage that has bothered so far. On 08/01/2014 05:12 AM, Michał Górny wrote: >> If we are to change our default dependency model, we need to do it >> properly - we need wider consensus, more open discussion of what's >> happening, and a proper plan of how to handle the pitfalls of the new >> model. Otherwise, we're just trading one set of problems for another. > > 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. What do you mean? Dynamic dependencies are the current default by definition. >> Specifically, I request the Council block the removal of dynamic >> dependencies until the following issues are resolved: >> >> 1. Although there has been considerable discussion[2] regarding dynamic >> dependencies in general, there has been no specific discussion regarding >> their actual removal. > > The thread pretty quickly turned into a bikeshed about that, so I don't > understand what you're talking about. Perhaps I missed it due to the size of the thread, but the discussion appeared to be more abstract rather than concerning any definite change. I see relatively little comment from Portage team members in any case. >> 2. The Portage team had made no announcement of their decision, nor do >> they apparently intend to until 30 days prior to a new Portage release. >> This is not adequate time for such a substantial change. > > I don't know what you mean by 'they apparently intend' but that sounds > offensive. I'd really prefer if you sticked to the facts. How is that offensive? It is the apparent intention I've been able to discern from the limited information the Portage team is providing. > The Portage team is going to announce the decision when it's final > and the code necessary for non-painful migration is in place. > Otherwise, the announcement would only bring barren discussion that > couldn't be supported by facts or numbers. This is not acceptable for such a significant change. >> 3. Few of the Portage team members were present[3] for the meeting, and >> no vote was held to reach the decision. > > I don't understand how this is relevant. It's not acceptable for one or two people to make a decision that affects the entire distribution, let alone if they don't have the consensus of their own team. >> 4. While there is a good description of the theoretical issues affecting >> both dependency models[4], multiple requests for specific examples of >> in-tree breakage have been ignored. This makes it difficult to assess >> the actual breakage that removing dynamic dependencies is supposed to >> address. > > The listing of theoretical issues is wrong and doesn't correspond to > Portage code, and yes, that's my fault. However, it only proves that > nobody on the thread bothered to look at the relevant Portage code, > even the people who started providing patches... The burden of proof is on the person wanting to make the change, so it would be nice if the Portage team would provide better information. Despite repeated requests, we have little information to substantiate claims like "it's fundamentally broken" and "dynamic dependencies is a bug. We decided to fix this regression." >> 5. The removal plan doesn't consider the impact from increased number of >> rebuilds due to revbumps containing only dependency changes. Without >> replacement functionality, widespread virtual or slot changes can cause >> hundreds of packages to be rebuilt. > > Please support this claim with specific examples or numbers. Otherwise, > it's just a 'theoretical issue' that you can't support. I'm happy to provide more examples beyond the 77 useless-but-apparently-acceptable rebuilds you mentioned below if necessary. It's not hard to check yourself, though. Almost 9000 ebuilds depend on virtual/pkgconfig. Even if we assume that any future virtual introduction will only affect an absolute maximum of 10% of that number of packages, that's still a ridiculous number of unnecessary rebuilds. > 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. Do you have some numbers to back up that statement? I can think of very few instances when I have had to rebuild against my will due to USE flag changes. > Yet the same people believe in > adding more flags to contain even more minor aspects of packages... Are you referring to flags for things like logrotate or systemd units? When they were around, I either had them enabled or I didn't - I was never forced to rebuild because of them.