On Sun, Jul 27, 2014 at 6:43 AM, Kent Fredric <kentfred...@gmail.com> 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
