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 C8A0713877A for ; Thu, 31 Jul 2014 19:12:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9F34FE07F5; Thu, 31 Jul 2014 19:12:28 +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 E4296E07F1 for ; Thu, 31 Jul 2014 19:12:27 +0000 (UTC) Received: from pomiot.lan (77-254-77-139.adsl.inetia.pl [77.254.77.139]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id BBC0534006F; Thu, 31 Jul 2014 19:12:25 +0000 (UTC) Date: Thu, 31 Jul 2014 21:12:39 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Michael Palimaka Cc: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: Call for agenda items - Council meeting 2014-08-12 Message-ID: <20140731211239.0eb282cb@pomiot.lan> In-Reply-To: References: <21463.26330.847055.224071@a1i15.kph.uni-mainz.de> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=pgp-sha512; boundary="Sig_/AAD+hy3TeUbsK5QwE=5r=p5"; protocol="application/pgp-signature" X-Archives-Salt: bd3dff41-e809-43a7-b8c9-5384032f7302 X-Archives-Hash: f9f2e890faf74141913e9ac11b88af79 --Sig_/AAD+hy3TeUbsK5QwE=5r=p5 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-08-01, o godz. 00:40:18 Michael Palimaka napisa=B3(a): > I am disappointed that the Portage team declined to bring the issue of > disabling dynamic dependencies to the Council's attention themselves. I don't understand your disappointment. If you disagree with portage team decision, it is your duty to bring it to the Council. > 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. > Specifically, I request the Council block the removal of dynamic > dependencies until the following issues are resolved: >=20 > 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. > 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. 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. > 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. > 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... > 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. 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... --=20 Best regards, Micha=B3 G=F3rny --Sig_/AAD+hy3TeUbsK5QwE=5r=p5 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT2pUoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOAYkP/3TmcJshjAUU6pbR6Isa3B9s cCfpMZgAbWvU6XztBKPv1kUTfFVHPSnFCwYufp+56tS++0j2CAjXTcMaB1ixBABj bddbCrWpKfE7Eti8nfqTmyk2p0XzzsLc30Q84A7KqZyR8kuNPAZPasPmR88v/dLY kaMbO0BueVP3yTXHyDP6N01Xqvu2HAdovU4t3xHj/p1kpXxkGZGzDEoyQw7RH1T/ Ol8dlKZgB66gK+tqTtIJChjISqG8OaMBKMEPbemF08gS7Qk9yafPk8thsh/C0sl2 zVmGQ7xSUhVtRs3edY93IwFaU3goswFzlrIn1BXgN8qvacox+En5qN8NdZOpJAqJ SAHujV4aogUqBO5uAN8Ecrb3weoBgkB0p8gHoS5a16BN7CbU/wDsjBCPKTdglg8j oMZY+/VrWVd+TP0wmLGz7U5zVgCjSgyomX9GoJJSDJxIEdg3xQ9VlAZpjbv+tL33 QtcJ3lUmnX0IV9WTDnT+KbrJyWE1vPjq7JgDIV5NBxa2k+Y70liiN1xdMLKHzF27 CWbjqV3WR6JWy0OPk4ElZE37wh4j+jB11aJWoHKreRLVNtPopO7KKGVHE4I+J4im gXXd8LSZau7kTryjY/IYS8TOsj+CsA00RCWoYYhi4Kkz3MDzTVUZlix01yiYA+AM iAun7Hnuo6TL5FOAWgXA =TZ4v -----END PGP SIGNATURE----- --Sig_/AAD+hy3TeUbsK5QwE=5r=p5--