Re: [gentoo-dev] What to do with people who use internal eclass functions?

[Rich Freeman]

On Mon, Aug 26, 2013 at 3:38 AM, Michał Górny <mgorny@g.o> 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