public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kent Fredric <kentfredric@gmail.com>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Proposal for changes for the next EAPI version
Date: Wed, 18 May 2016 12:44:26 +1200	[thread overview]
Message-ID: <CAATnKFB=NBPN5o2sEfhvX6QGy_+wK=g8yZX0XSCwGH2fDULrOw@mail.gmail.com> (raw)
In-Reply-To: <573BB8C7.9020400@iee.org>

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 ).

-- 
Kent

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


  reply	other threads:[~2016-05-18  0:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-16 12:43 [gentoo-dev] Proposal for changes for the next EAPI version Pallav Agarwal
2016-05-16 16:38 ` Luis Ressel
2016-05-17  7:37   ` Pallav Agarwal
2016-05-17  8:02     ` Kent Fredric
2016-05-17  8:46       ` Tobias Klausmann
2016-05-17  9:15         ` Kent Fredric
2016-05-17 10:57           ` Rich Freeman
2016-05-17 11:25             ` Pallav Agarwal
2016-05-17 11:42               ` Rich Freeman
2016-05-17 10:01         ` Pallav Agarwal
2016-05-17 11:26           ` Michael Orlitzky
2016-05-17 11:29             ` Ciaran McCreesh
2016-05-18  8:18               ` [gentoo-dev] " Duncan
2016-05-17 13:53     ` [gentoo-dev] " M.B.
2016-05-17 14:02       ` Brian Dolbec
2016-05-17 15:34     ` Luis Ressel
2016-05-17 16:05       ` Sébastien Fabbro
2016-05-17 16:42         ` Rich Freeman
2016-05-18  0:14         ` Kent Fredric
2016-05-18  0:35           ` M. J. Everitt
2016-05-18  0:44             ` Kent Fredric [this message]
2016-05-18  0:48               ` M. J. Everitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAATnKFB=NBPN5o2sEfhvX6QGy_+wK=g8yZX0XSCwGH2fDULrOw@mail.gmail.com' \
    --to=kentfredric@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox