On Wed, 2 Dec 2015 13:04:19 +0100 Ulrich Mueller <u...@gentoo.org> wrote:
> >>>>> On Wed, 2 Dec 2015, Alexis Ballier wrote: > > > What's the point, need or advantage in moving this to > > all-ebuild-scope? > > > Usually eclass refactor/api cleanup are done in a -r{n+1} while > > deprecating -rn. This would have the advantage that you can quickly > > post a complete implementation and get wider reviews. > > A proof-of-concept implementation for the two version manipulation > functions is here: > https://482170.bugs.gentoo.org/attachment.cgi?id=418072 > Add some comments and you'll have a working eclass. :) Yes, but I don't see the point of defining bash code in PMS and copy/pasting it in every compliant PM, when said code used to be in only one place. Sounds like a "regression" to me. [...] > Also version_test is missing, but the idea there was to avoid > redundancy and use the implementation that already exists in the > package manager (which does version comparison all the time). This is > one of the reasons for moving it to the package manager. well, then maybe version_test is the only one that makes sense to be added to PM. Though it is unclear to me how to interface it: spawning a python interp. every time the function is called doesn't seem to be a terrible idea wrt performance.