Re: [gentoo-dev] Avoiding rebuilds (was: don't rely on dynamic deps)

[Rich Freeman]

On Sun, Jul 27, 2014 at 6:16 AM, Ulrich Mueller <ulm@g.o> wrote:
> I wonder if it wouldn't be saner to leave our revision syntax
> untouched.
>
> Instead, one could introduce a variable INSTALL_VERSION that would
> default to ${PVR} but could be set to the version of a previous ebuild
> instead. The PM could compare it against INSTALL_VERSION in the VDB
> and skip build and installation if versions match.
>
> Advantages:
> - Support for the variable could be optional. PMs not supporting it
>   would do a regular revbump instead.
> - One could even imagine USE-conditional syntax for the variable.

This isn't all that different from the concept I put out around having
the PM cache hashes of last-seen ebuilds, except that the hash is
editable so that developers can mess with it this way, allowing
revbumps to avoid rebuilds.

If an eclass/virtual/etc change impacted 200 packages, would you then
revbump all of them but setting INSTALL_VERSION on all the bumps?
That could involve a lot of ebuild munging.  Also, if you add
hard-coded INSTALL_VERSIONs to ebuilds that lacked them previously,
maintainers would have to notice that and remove those the next time
they did a bump or even a non-revbump might not trigger a rebuild
since it is still pointing to the old minor revision.

I take it that we would also have the package manager not do dynamic
deps if the revision doesn't change if we used the INSTALL_VERSION
approach?

This scenario still beg's Kent's question, "why do we have to point
out to portage that the deps need reparsing?"  If we're going to have
dynamic deps, then shouldn't reparsing deps be the default when they
change, and rebuilds should be the fallback when a big change happens
that dynamic deps can't handle?  If so, then we already have a
mechanism for that - you change the revision when you want a rebuild,
and then this just comes down to devs revbumping when they need to,
and having the PM able to detect other changes and properly handle
them.

And yes, I know the argument is that some changes can never be
properly handled, but my point is that we only use dyanmic deps for
changes which can be handled properly, so we're just arguing over
whether that is the empty set or not.

Rich