| 1 |
On Wed, 23 May 2012 11:28:13 +0300 |
| 2 |
Petteri Räty <betelgeuse@g.o> wrote: |
| 3 |
|
| 4 |
> On 22.5.2012 8.53, Michał Górny wrote: |
| 5 |
> >> Excuse me but the way this change was handled is a bit depressing. |
| 6 |
> >> First, the ebuilds should have been fixed to inherit eutils and then |
| 7 |
> >> remove eutils from autotools. Now, a bunch of ebuilds are broken out |
| 8 |
> >> of nowhere. I don't believe this issue was that urgent in order to |
| 9 |
> >> justify the significant breakage of portage tree. |
| 10 |
> > |
| 11 |
> > First of all, to quote devmanual: |
| 12 |
> > |
| 13 |
> > | Before updating eutils or a similar widely used eclass, it is best to |
| 14 |
> > | email the gentoo-dev list. It may be that your proposed change is |
| 15 |
> > | broken in a way you had not anticipated> [...]. If you don't email |
| 16 |
> > | gentoo-dev first, and end up breaking something, expect to be in a |
| 17 |
> > | lot of trouble. |
| 18 |
> > |
| 19 |
> > Not that this disrespect for this rule is something new... |
| 20 |
> > |
| 21 |
> |
| 22 |
> Even more important is the next chapter: |
| 23 |
> |
| 24 |
> "When removing a function or changing the API of an eclass, make sure |
| 25 |
> that it doesn't break any ebuilds in the tree, and post a notice to |
| 26 |
> gentoo-dev at least 30 days in advance, preferably with a patch included." |
| 27 |
> |
| 28 |
> This qualifies as changing the API of an eclass. This chapter comes from |
| 29 |
> a council decision: |
| 30 |
> |
| 31 |
> http://www.gentoo.org/proj/en/council/meeting-logs/20111108-summary.txt |
| 32 |
|
| 33 |
I don't see how removing an inherit is breaking an eclass' API. The |
| 34 |
functionality of the eclass itself does not change. Yes if you want to get |
| 35 |
technical you previously had access to functions from other eclasses by |
| 36 |
reaching through it, but that's a side effect that shouldn't be relied upon. |
| 37 |
If we do, then making a change to an eclass not only requires an audit of all |
| 38 |
the ebuilds using that eclass, but also any eclasses that inherit it and all |
| 39 |
of their ebuilds and so on and so forth. Ebuilds should be inheriting what |
| 40 |
they need, not relying on other eclasses to do it for them (the exception of |
| 41 |
course is "meta" or "base" type eclasses like kde, gnome, or java (i think?) |
| 42 |
that are designed to work this way). The breakage here is a perfect example |
| 43 |
how a simple change can have consequences that even a senior developer can |
| 44 |
overlook when this practice isn't followed. |
| 45 |
|
| 46 |
That said, I do think adding the eutils inherit back until people can audit |
| 47 |
their ebuilds seems like the sanest thing to do. Normally I'd say just fix |
| 48 |
your ebuilds, but I hate it when stable breaks. |
| 49 |
|
| 50 |
|
| 51 |
-- |
| 52 |
fonts, gcc-porting |
| 53 |
toolchain, wxwidgets |
| 54 |
@ gentoo.org |
Archives