From: Zac Medico <zmedico@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: "Michał Górny" <mgorny@gentoo.org>, zerochaos@gentoo.org
Subject: Re: [gentoo-dev] cmake-utils.eclass and bug 475502
Date: Thu, 18 Jul 2013 15:11:00 -0700 [thread overview]
Message-ID: <51E867F4.9090109@gentoo.org> (raw)
In-Reply-To: <20130718090641.2956d27c@gentoo.org>
On 07/18/2013 12:06 AM, Michał Górny wrote:
> Dnia 2013-07-17, o godz. 17:42:32
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> napisał(a):
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
>> On 07/17/2013 05:34 PM, hasufell wrote:
>>> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
>>>> ...and that is why it isn't permitted to directly use an eclass
>>>> that you don't inherit. While I agree testing could (should) have
>>>> been better, the fact that people ignore the rules for writing
>>>> ebuilds shouldn't entirely fall on the KDE team.
>>>
>>>
>>> It doesn't matter in the slightest whos fault it is or who should be
>>> blamed.
>>>
>>> It is about maintaining stability for the user. Especially when it
>>> comes to stable ebuilds.
>>>
>>> That means the methods for eclass changes must be more thoroughly.
>
>> I completely agree with you, the changes should have been tested better.
>> The ebuilds with these errors popping up ALSO should have been tested
>> better. Considering this is a QA violation, perhaps it is possible to
>> add a check in repoman for using something from an eclass which you
>> didn't inherit. I doubt the slowdown would be horrible and clearly it
>> would catch a huge number of QA violations.
>
> Repoman has such check already. It pops up for specific functions
> listed in repoman source code. This allows us to catch the common
> mistakes while avoiding false positives.
>
> Maybe it should always pop up for phase functions. I don't immediately
> see a reason why an ebuild would use a phase function of an eclass it
> doesn't inherit directly.
That check is only enabled in portage-2.2, because I really want it to
parse the relevant info directly from the eclasses. That way, we won't
have to update repoman for eclass changes.
--
Thanks,
Zac
next prev parent reply other threads:[~2013-07-18 22:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 20:57 [gentoo-dev] cmake-utils.eclass and bug 475502 hasufell
2013-07-17 21:17 ` Chris Reffett
2013-07-17 21:28 ` Rick "Zero_Chaos" Farina
2013-07-17 21:34 ` hasufell
2013-07-17 21:42 ` Rick "Zero_Chaos" Farina
2013-07-17 21:47 ` hasufell
2013-07-17 21:55 ` Rick "Zero_Chaos" Farina
2013-07-17 22:15 ` hasufell
2013-07-18 7:06 ` Michał Górny
2013-07-18 22:11 ` Zac Medico [this message]
2013-07-17 23:09 ` Tom Wijsman
2013-07-18 16:40 ` Alexis Ballier
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=51E867F4.9090109@gentoo.org \
--to=zmedico@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mgorny@gentoo.org \
--cc=zerochaos@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