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