On Mon, 26 Aug 2013 09:38:04 +0200 Michał Górny <mgo...@gentoo.org> wrote:
> I've noticed that some people are using internal eclass functions > in their ebuilds. I mean, functions that are explicitly marked > @INTERNAL and that start with an underscore. What should I do to them? First, figure out why they use the internal eclass function: - Does the ebuild really need what the internal function does at all? - Is there a non-internal eclass function they can use instead? - Does the eclass not fit the use case of the package? Depending on these questions, you'll either need to file a bug for the developer to fix it _or_ need to make adjustments to the eclass. > I would expect that Gentoo developers are professionals. Or at least > semi-reasonable people. Yet it seems that I was mistaken. Yet, they hack a workaround once in a hundred (semi) or thousand (pro). > We were never pinged about the internal function use. Nobody bothered > to ask us why the function is internal and what they should they use > instead. I guess it was the usual 'it works, i don't care' case. Agreed, it should have been communicated to you; while you could theoretically read through all the ebuilds, the most reasonable thing you can only do is properly document the eclass and its proper uses. If they use internal functions without letting you know, not your fault... > What should I do now? Mask the ebuild? Proceed with changing > the function and break it? Evaluate the use case and file a bug or make eclass adjustments. The ebuild isn't broken so it might not need a mask; you might be able to consider this a QA violation, if so, skip the bug and fix it yourself. > Or maybe do we need to have GPG signature verification of bash > tracebacks in every internal function to prevent developers from > using those? Things like that seem overly complicated for what you want to do; it isn't so much that it is a bad thing to implement, but it is rather that the more complicated you make it the harder it gets to implement. The idea of adding QA checks to repoman sounds sane; it could probably easily build a whitelist of internal eclass functions (it already does for other things), after that it just has to match them in the ebuild. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
