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 67B7613877A for ; Mon, 28 Jul 2014 18:27:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8842BE0CBB; Mon, 28 Jul 2014 18:27:11 +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 8CE19E0CAC for ; Mon, 28 Jul 2014 18:27:10 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 4170433F7F8 for ; Mon, 28 Jul 2014 18:27:09 +0000 (UTC) Message-ID: <53D695F6.7050302@gentoo.org> Date: Mon, 28 Jul 2014 14:27:02 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: don't rely on dynamic deps References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8f302f1a-33ff-43b6-952f-ffecec4bdb28 X-Archives-Hash: 1a484e8c99b5d093c9d0535feebfd061 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 27/07/14 08:04 AM, Rich Freeman wrote: > On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric > wrote: >> >> In a "no dynamic deps, period" scenario, this just strikes me as >> 2 flavours of the same weirdness, -r2 and -r1.1 are just equally >> weird choices to make if the ebuild itself doesn't change at >> all. > > You have a good point here. > > With this proposal we have three kinds of ebuild changes: 1. Those > that do not involve any revbump. 2. Those with a "minor" revbump > (ie -r1 -> -r1.1). 3. Those with a normal revbump (ie -r1 -> > -r2). > > What is the purpose of allowing the first? Presumably that should > be used in even more limited circumstances than a minor revbump, so > why allow it at all? Why not just make an in-place change > equivalent to a minor revbump and ditch the minor revbump entirely? > Devs would still need to distinguish between what requires a > revbump and what does not. > > Doing this would require having portage cache a hash of whatever > ebuild it last parsed, and perhaps its eclasses as well if we > permit revbump-less eclass changes. Then it would have to check > for when these change, perhaps this might be stored in the metadata > to speed things up. > > You could view such an approach as being equivalent to just > sticking a ".hash" on every ebuild in the tree as a minor revision > tag, so that any change triggers a minor revision. The only > difference between that and the proposal that I can see is that the > minor revisions would be unordered. However, if we go with the > theory that defective ebuilds get removed immediately then there is > no point in ordering minor revisions because there will only be one > in the tree at any time for a given major revision, so the package > manager couldn't take advantage of any information conveyed by > ordering. > > This probably isn't too different from what portage is doing > already, except: 1. Portage is only looking for dependency changes > when it has another reason to look closely at the ebuild - it has > no mechanism to detect that an ebuild changes, and this would add > one. 2. We don't have any clear policies today on when ebuilds > should be revbumped or not as the result of things like dependency > changes, and this would cause us to make some. > > The fact that this isn't a big change does concern me that it may > not fix all of the underlying problems. However, some of those > problems might not actually have clean solutions other than never > committing mistakes in the first place. For example, if a prerm > dependency was missing then removing the ebuild can potentially > fail whether you use dynamic deps or not until it is satisfied. > The primary underlying problem I see about this is that it doesn't force devs to start doing something to the tree that will suddenly help make all of the static-deps-only PMs (ie, those that aren't going to implement this new hash-changed-so-re-evaluate-ebuild method) suddenly work in a more consistent fashion. IIRC, the very first post of this thread was a reminder to dev's to revbump so that static-deps behaviour is more correct/consistent. However, if we put something into the next EAPI about this and make it a requirement for all PMs (although I have no idea how we would roll this out; maybe make it a profile-level requirement instead of an ebuild-level one, if there is such a thing??) then it would become much less of an issue.. Mind you, we need to solve all of the problems first and make sure PMS documents all of the requirements in an appropriately complete and ambiguity-preventing manner that everyone agrees with.. Easy, right? :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPWlfYACgkQ2ugaI38ACPApTwD9H+PX4f1XGtauwbjfXczPqAYf yBqDW9MOwIlWPCqeu6IA/ipySyWxA/J12RSuLTNyj98li9Qmeq0GLR37KSZ2Cc/p =05lZ -----END PGP SIGNATURE-----