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

["M. J. Everitt" <m.j.everitt@iee.org>]

[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]

On 18/05/16 01:44, Kent Fredric wrote:
> On 18 May 2016 at 12:35, M. J. Everitt <m.j.everitt@iee.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 ).
>
Yes, I get where you're coming from. I think many of the language and
language-plugin ebuilds are going to suffer from similar problems for
exactly the reasons you describe. It does make the prospect of a good,
over-arching QA/CI system quite challenging (but not impossible) to
achieve .. !!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]