| 1 |
On Tuesday 09 April 2013 14:12:33 Donnie Berkholz wrote: |
| 2 |
> On 23:20 Mon 08 Apr , Ryan Hill wrote: |
| 3 |
> > Hrm. I just meant that package eclasses suck. I hate the fact that they |
| 4 |
> > effectively make stable moot. There is no such thing as a stable keyword |
| 5 |
> > for a package built by an eclass. It's like working without a net. |
| 6 |
> > When it's a core system package it's twice as bad. |
| 7 |
> > |
| 8 |
> > As far as these eclasses go, toolchain is the worst. Yes, it is fragile |
| 9 |
> > and complex. It's over a decade's worth of spaghetti code. It builds 12 |
| 10 |
> > years of gcc releases. It's hairy. Everything depends on everything |
| 11 |
> > else, and everything is based on assumptions and implications that may |
| 12 |
> > or may not still be relevant. Making "obviously" correct changes has |
| 13 |
> > often broken something somewhere else, time and again. I'm not telling |
| 14 |
> > you this for some kind of perverse bragging rights. It's not something |
| 15 |
> > to be proud of. I just want you to understand how easy it is to fuck |
| 16 |
> > things up. |
| 17 |
> > |
| 18 |
> > When it breaks, it breaks stable. I absolutely hate breaking stable. I |
| 19 |
> > lose sleep over it. |
| 20 |
> |
| 21 |
> You could probably deal with this through much more aggressive bumping |
| 22 |
> of eclass versions in concert with ebuild bumps, followed by eclass |
| 23 |
> freezes once their users go stable. |
| 24 |
|
| 25 |
we can could create a "toolchain-stable.eclass". whenever we stabilize a new |
| 26 |
version, we copy the current toolchain.eclass to toolchain-stable.eclass and |
| 27 |
change the newly stabilized ebuild to inherit that instead. |
| 28 |
|
| 29 |
for all other versions (unstable, and older stable), we have them use the |
| 30 |
toolchain.eclass. |
| 31 |
-mike |
Archives