| 1 |
On Thu, 06 Nov 2014 13:42:43 -0800 |
| 2 |
Zac Medico <zmedico@g.o> wrote: |
| 3 |
|
| 4 |
> On 11/06/2014 01:32 PM, Jeroen Roovers wrote: |
| 5 |
> > I'm not aware of any current definition of order in eclass |
| 6 |
> > inheritance. |
| 7 |
> |
| 8 |
> Maybe PMS doesn't say anything about the order (yet). However, I'm |
| 9 |
> fairly sure that all package managers process eclasses in the same |
| 10 |
> order that they are passed as arguments to inherit. Otherwise, |
| 11 |
> eclasses would not be able to properly override functions defined by |
| 12 |
> eclasses earlier in the inherit chain. |
| 13 |
|
| 14 |
If the order is important, then the ebuild should call each phase or |
| 15 |
utility function explicitly. Expecting the order of inheritance to |
| 16 |
convey the same thing instead of making explicit calls might work from |
| 17 |
the package manager's perspective, but the ebuild writer is lost in the |
| 18 |
woods. With that in mind we might argue that a change in the order of |
| 19 |
inheritance should never cause a different outcome. |
| 20 |
|
| 21 |
> In the context of future.eclass, eutils and multilib could simply |
| 22 |
> check if the relevant functions were defined earlier, and die in that |
| 23 |
> case. |
| 24 |
|
| 25 |
Would the bash internal `readonly -f' work for that? |
| 26 |
|
| 27 |
> > We sure have issues with inheriting eclasses in a different order |
| 28 |
> > giving different results now. Is this something that's in the works |
| 29 |
> > for a future EAPI, then? |
| 30 |
> |
| 31 |
> No, but as said, I'm fairly sure that all package managers process |
| 32 |
> eclasses in the same order that they are passed as arguments to |
| 33 |
> inherit. |
| 34 |
|
| 35 |
Well, that's convenient but you should probably not start relying on |
| 36 |
it now. In that case we might want to discuss inheriting in |
| 37 |
alphabetical order and numbering the eclasses cleverly, too. Or rename |
| 38 |
this one to zfuture.eclass. |
| 39 |
|
| 40 |
|
| 41 |
jer |
Archives