On Sun, Jul 27, 2014 at 8:04 AM, Rich Freeman <ri...@gentoo.org> wrote: > > 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.
I was thinking about this a little more, and the way I'd do it is ID whatever ebuild variables we want to allow to be dynamic. Then the ebuild would be sourced, and then those variables would be extracted and hashed, and that would be treated as the ebuilds dependency state. That would be stored in the metadata, and portage would store it in vdb when a package is installed. Then portage could look for any change in state and that would trigger a build-less re-merge, which would update vdb with the new state (including the new hash). With this approach you don't need minor revision numbers - any change to an ebuild would be considered a minor revision, and when that is inappropriate a full revbump should be used instead. Rich
