public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] cmake-utils.eclass and bug 475502
Date: Wed, 17 Jul 2013 17:55:18 -0400	[thread overview]
Message-ID: <51E712C6.2070003@gentoo.org> (raw)
In-Reply-To: <51E71102.6040103@gentoo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2013 05:47 PM, hasufell wrote:
> On 07/17/2013 11:42 PM, Rick "Zero_Chaos" Farina wrote:
>> On 07/17/2013 05:34 PM, hasufell wrote:
>>> On 07/17/2013 11:28 PM, Rick "Zero_Chaos" Farina wrote:
>>>> On 07/17/2013 05:17 PM, Chris Reffett wrote:
>>>>> On 07/17/2013 04:57 PM, hasufell wrote:
>>>>>> I know there was an announcement about the upcoming change
>>>>>> to cmake-utils.eclass, however... it is not enough to give
>>>>>> a deadline without caring if people actually fixed it by
>>>>>> then.
> 
>>>>>> By doing that you risk breaking stable packages which is
>>>>>> not trivial.
> 
>>>>>> You _must_ do a tinderbox run, test that stuff in an
>>>>>> overlay or whatever. You are responsible for ALL reverse
>>>>>> deps.
> 
>>>>>> The way it was done... was not appropriate. Please be more 
>>>>>> careful next time. There are still incoming bugs about
>>>>>> broken base_src_* calls. (see the tracker)
> 
> 
>>>>> I discussed this with hasufell on IRC, but I'll lay out the 
>>>>> response on the list too. Yes, this was my fault. We (KDE
>>>>> team) tested in our overlay, but none of the packages there
>>>>> use the base_src_* calls, which is why it didn't come up in
>>>>> testing, and I did not realize that there were packages that
>>>>> did rely on the implicit base inherit to call base_src_*
>>>>> directly.
> 
>>>> ...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.
> 
> 
>> 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.
> 
> 
> That will yield false positives. Some eclases are explicitly designed
> in a way that you do NOT need to directly inherit it's helpers such as
> python-r1 and python-utils-r1.
> 
> 
It is my understanding that if you directly use a function from an
eclass you are REQUIRED to inherit that eclass.  Given that kind of
sanity would have prevented these failures I find it difficult to
believe my understanding is wrong, but I am willing to learn.

I think I'll start inheriting base.eclass so I can use multilib
functions.  I mean, base.eclass inherits eutils.eclass which inherits
multilib.eclass so it should work out fine, right?

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5xLGAAoJEKXdFCfdEflKe/sP/jo7mFijN9jzpbK4/4IAigR/
CuF+gyMh6r8fxDRCKBZ02T04hMhM6XDbafNKGaDstXbLLI6o6xAgGLboeZxo6tj+
GFD+u4gqjN4EWRGeuHS+bzJErEBEt1XpMecaPHyNs6CZF+/XTL6zOZOsKWYAELzO
1mlTLp5dn4XCbtC8llsgey1sxq42kuN93JWRqODVPlU5lwZD7cbTpgVV6nQrz36n
NeS0FfjIs/UN8/Rix0xaC4frEG86Zv+ES1R/HB6UqDhx+P1hdRpBGVTNF6eLOMvV
JJA735pWeN6xgcdrcOrCIGVQTfptaD+tlYfSjL1aeN/Bw1LemyChwsCHd5PE8sgv
z63zTiMvR4Mm12KG8xYtm2ygTSdrjCvZz5/ZaX6wnJuCAALGs6Z2dTa27YQBBtlD
z4UXXG1fWImcYL1J26rMzapzSzQeXPYThedpCSRIiIs876RQhuE/M7/ZACNveTAR
I5QwxY9ZOtol9+ucvRn+8BqS24pRw0DwlWEUTYOWxHcgcMHFw3EzH0Zy0AUYj7yc
JrawQlWrhtSYSzScEpEvwlbU+zvZbWi/BXo+K8gUGq+hqseq2vLcfAyTzUA/lyYS
oBeAlJVBxFBKsO/64byItWY0la5E4w8T6qy+sgFvlnoFG3rO+/jWSfiEhDOSffCS
BLycpk3pzcBSOmTBnJrf
=Xgsq
-----END PGP SIGNATURE-----


  reply	other threads:[~2013-07-17 21:55 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 [this message]
2013-07-17 22:15             ` hasufell
2013-07-18  7:06         ` Michał Górny
2013-07-18 22:11           ` Zac Medico
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=51E712C6.2070003@gentoo.org \
    --to=zerochaos@gentoo.org \
    --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