| 1 |
On Mon, 26 Aug 2013 09:38:04 +0200 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> I've noticed that some people are using internal eclass functions |
| 5 |
> in their ebuilds. I mean, functions that are explicitly marked |
| 6 |
> @INTERNAL and that start with an underscore. What should I do to them? |
| 7 |
|
| 8 |
First, figure out why they use the internal eclass function: |
| 9 |
|
| 10 |
- Does the ebuild really need what the internal function does at all? |
| 11 |
|
| 12 |
- Is there a non-internal eclass function they can use instead? |
| 13 |
|
| 14 |
- Does the eclass not fit the use case of the package? |
| 15 |
|
| 16 |
Depending on these questions, you'll either need to file a bug for the |
| 17 |
developer to fix it _or_ need to make adjustments to the eclass. |
| 18 |
|
| 19 |
> I would expect that Gentoo developers are professionals. Or at least |
| 20 |
> semi-reasonable people. Yet it seems that I was mistaken. |
| 21 |
|
| 22 |
Yet, they hack a workaround once in a hundred (semi) or thousand (pro). |
| 23 |
|
| 24 |
> We were never pinged about the internal function use. Nobody bothered |
| 25 |
> to ask us why the function is internal and what they should they use |
| 26 |
> instead. I guess it was the usual 'it works, i don't care' case. |
| 27 |
|
| 28 |
Agreed, it should have been communicated to you; while you could |
| 29 |
theoretically read through all the ebuilds, the most reasonable thing |
| 30 |
you can only do is properly document the eclass and its proper uses. If |
| 31 |
they use internal functions without letting you know, not your fault... |
| 32 |
|
| 33 |
> What should I do now? Mask the ebuild? Proceed with changing |
| 34 |
> the function and break it? |
| 35 |
|
| 36 |
Evaluate the use case and file a bug or make eclass adjustments. The |
| 37 |
ebuild isn't broken so it might not need a mask; you might be able to |
| 38 |
consider this a QA violation, if so, skip the bug and fix it yourself. |
| 39 |
|
| 40 |
> Or maybe do we need to have GPG signature verification of bash |
| 41 |
> tracebacks in every internal function to prevent developers from |
| 42 |
> using those? |
| 43 |
|
| 44 |
Things like that seem overly complicated for what you want to do; it |
| 45 |
isn't so much that it is a bad thing to implement, but it is rather |
| 46 |
that the more complicated you make it the harder it gets to implement. |
| 47 |
|
| 48 |
The idea of adding QA checks to repoman sounds sane; it could probably |
| 49 |
easily build a whitelist of internal eclass functions (it already does |
| 50 |
for other things), after that it just has to match them in the ebuild. |
| 51 |
|
| 52 |
-- |
| 53 |
With kind regards, |
| 54 |
|
| 55 |
Tom Wijsman (TomWij) |
| 56 |
Gentoo Developer |
| 57 |
|
| 58 |
E-mail address : TomWij@g.o |
| 59 |
GPG Public Key : 6D34E57D |
| 60 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives