From: Ulrich Mueller <ulm@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: "Marty E. Plummer" <hanetzer@startmail.com>
Subject: Re: [gentoo-dev] [PATCH] eutils.eclass: split unique functions into eutils-r1
Date: Sun, 8 Apr 2018 15:26:43 +0200 [thread overview]
Message-ID: <23242.6291.557195.170183@a1i15.kph.uni-mainz.de> (raw)
In-Reply-To: <20180408122929.20363-1-hanetzer@startmail.com>
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]
>>>>> On Sun, 8 Apr 2018, Marty E Plummer wrote:
> Split all functions unique to eutils into eutils-r1, and inherit it
> from eutils. Issue a QA warning on EAPI=6 ebuilds using eutils directly
> and suggest migrating to direct use of the needed eclass, with a list of
> functions unique to eutils-r1.
> With this we can start moving ebuilds which inherit eutils because they
> need a function unique to the old eutils to eutils-r1, while being able
> to single out ebuilds which used eutils to inherit other ebuilds lazily
> or just cargo cult coding of always inheriting eutils.
I fear that at this point, shortly before approval of EAPI 7, this
doesn't make much sense. More than half of the tree is at EAPI 6, so
that QA warning would be shown for many ebuilds.
Also in EAPI 7 some functions won't be in eutils any more. For example,
eqawarn will be provided by the package manager. So that -r1 eclass
would start out with ugly EAPI conditionals.
So, IMHO the cleaner procedure is to wait with this for EAPI 7, where
we may be able to do the migration without a revision bump of the
eclass.
Ulrich
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2018-04-08 13:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-08 12:29 [gentoo-dev] [PATCH] eutils.eclass: split unique functions into eutils-r1 Marty E. Plummer
2018-04-08 13:26 ` Ulrich Mueller [this message]
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=23242.6291.557195.170183@a1i15.kph.uni-mainz.de \
--to=ulm@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=hanetzer@startmail.com \
/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