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 |