Re: [gentoo-dev] cmake-utils.eclass and bug 475502

[Rick \\\"Zero_Chaos\\\" Farina]

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