Re: [gentoo-dev] Proposal for changes for the next EAPI version

[Kent Fredric]

On 18 May 2016 at 12:35, M. J. Everitt <m.j.everitt@×××.org> wrote:
> Yes, whilst that's a special case, it would be desirable to collaborate
> with another maintainer/team/project to devise a test schedule that was
> independent from the target language, if possible. But there will always
> be exceptions and issues and such with these things .. :/


In some of these cases, the things I'd be testing have to rely on Perl
Modules *because* it has to track how those specific modules respond
to the code in question.

For instance, to check we're doing our version normalisation
correctly, we have to use the upstream reference version of Perl's
version handling code directly.

*NOT* doing this results in significant problems, both in our failure
to perfectly map upstreams implementation in a different language, and
in our ability to keep our implementation in consistency with upstream
changes.

And we have already suffered this problem specifically in euscan,
where the euscan project implemented the version interpretation logic
manually, and did so hilariously wrong, and as a result, thinks newer
versions are older versions a lot of the time, and vice versa. I've
attempted my own implementation of upstreams logic *better* than I
think euscan does it, but I'm trapped in the reality where I have *no*
objective way of knowing if it in fact, represents upstreams logic
correctly.

The simplest thing to say here is "implementing it in a non-target
language is often enough the wrong choice".

Similarly, I've made the mistake of trying to understand and interpret
ebuilds statically without using bash .... that's a road to nowhere.
Even using bash is a bit tortured because I can't understand how an
ebuild works without reimplementing all the EAPI parts in bash or
relying on some portage version of the same ( which is extremely not
easy to use outside of the portage tools ).

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL