On Mon, Aug 26, 2013 at 3:38 AM, 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?
Seems crazy to need a written policy to not do something so dumb... > What should I do now? Mask the ebuild? Proceed with changing > the function and break it? Seems like masking and changing is the most appropriate course of action. By all means log a bug and give the maintainer a week or whatever. The only exception I'd make would be for important packages. I wouldn't make it because their maintainers are important, but because we care about our users. Obviously we can't go masking bash or whatever. However, we should in general consider the use of internal functions a QA issue, and follow-up with the devs doing so. Maybe burning at the stake is a bit harsh since the issue hasn't come up before, but there is no excuse for this. > > Or maybe do we need to have GPG signature verification of bash > tracebacks in every internal function to prevent developers from using > those? This is not a technical problem, it is a people problem. If any internal functions lack underscores or are referenced in the devmanual/etc those should be fixed, and /maybe/ a repoman warning would be helpful (really? a developer might not realize they've used an undocumented internal function?). Sure, maybe some of those internal functions are useful and should turn into published APIs. Devs are welcome to step up and do just that if it makes sense (and following the normal eclass process). However, devs are not welcome to just use internal APIs and then make users deal with the aftermath when ebuilds break. Using internal APIs is bad practice - if anybody doesn't already understand why they're probably on the wrong list. Rich
