| 1 |
On Wed, Apr 10, 2013 at 3:30 PM, Mike Frysinger <vapier@g.o> wrote: |
| 2 |
> we can could create a "toolchain-stable.eclass". whenever we stabilize a new |
| 3 |
> version, we copy the current toolchain.eclass to toolchain-stable.eclass and |
| 4 |
> change the newly stabilized ebuild to inherit that instead. |
| 5 |
> |
| 6 |
> for all other versions (unstable, and older stable), we have them use the |
| 7 |
> toolchain.eclass. |
| 8 |
|
| 9 |
That sounds slightly better than how a few infamous libs handle |
| 10 |
SONAMEs and ABIs. |
| 11 |
|
| 12 |
I think the real problem is that we're defining functions without |
| 13 |
clearly defining the inputs and outputs. The input is essentially a |
| 14 |
tarball or directory tree that is expected to be in a fairly |
| 15 |
particular format, but upstream does not commit to keeping these |
| 16 |
formats across versions. |
| 17 |
|
| 18 |
This is like defining a function in an eclass that takes two integers |
| 19 |
as parameters, and then in the next eclass revision having it take two |
| 20 |
strings. That is obviously going to create a mess unless you |
| 21 |
carefully modify all the references to that function on every bump. |
| 22 |
Heaven forbid anybody with an overlay wants to use it. |
| 23 |
|
| 24 |
toolchain.eclass is only used by gcc, kgcc64, and gcc-apple. Would it |
| 25 |
just make more sense to inline it? That makes all these issues go |
| 26 |
away - each version has its own independent quality process and there |
| 27 |
is no risk of changes breaking things across versions. |
| 28 |
|
| 29 |
Rich |
Archives