Re: [gentoo-dev] Re: don't rely on dynamic deps

[Rich Freeman]

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