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 5D4A413877A for ; Sun, 27 Jul 2014 12:04:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1CCE0E0E0B; Sun, 27 Jul 2014 12:04:40 +0000 (UTC) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 38F79E0C7C for ; Sun, 27 Jul 2014 12:04:38 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id hq11so9940326vcb.2 for ; Sun, 27 Jul 2014 05:04:38 -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:content-type; bh=IpDcKOjmYjOPi778oahetv0i4/fWVbzSTmz5boIAsFs=; b=eRTtElYlcvh/vJjYAdXPui5+3csCghwAhY1btPVby5Pk1lBWrYcGL0sEq3Bh1OaoMj m223hdb2hsMy/pUofCFBiJ9UETiYhrS/IeA9n8Z7GSGVINCBvda69Nmh8BqXCDJn1DNp BH7MHWb4+bM7Dqodq20x+thgC7thq9fqoU406p1yR5mP7Z9qeZCWU/jNVP9Ci2I/ycBq Uh0R5bWFA63+t82By6pYWq4IjLHU6WBLC99YUmKVNU/6QAuYLaL1Ia+iGaJnbrEDVNFu 43fnH9Syl0R9EAR8TljfdEroI1cB/fw9/DnwS1L3dpwob+oxRBgpe1CxCFhszG4DV4G1 pzhw== 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 X-Received: by 10.221.56.132 with SMTP id wc4mr7346863vcb.38.1406462678216; Sun, 27 Jul 2014 05:04:38 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Sun, 27 Jul 2014 05:04:37 -0700 (PDT) In-Reply-To: References: <53CD6BED.10603@gentoo.org> <53CD8BBA.2010605@gentoo.org> <53CE11F9.8020700@gentoo.org> Date: Sun, 27 Jul 2014 08:04:37 -0400 X-Google-Sender-Auth: mkS9DCN0DWsjwdo7NCo8Bf3iEgQ Message-ID: Subject: Re: [gentoo-dev] Re: don't rely on dynamic deps From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 78633c61-4a5f-4f9c-8dda-909df3e2f31e X-Archives-Hash: 4f41a14a6e469ef62dbd7cc7e113929a 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. Rich