| 1 |
"Rick \"Zero_Chaos\" Farina" <zerochaos@g.o> writes:
|
| 2 |
|
| 3 |
> While I'm not nearly good enough to detail how this should happen |
| 4 |
> exactly, please, may I beg, do an eclass revision for this. |
| 5 |
|
| 6 |
There is an r1 candidate as Paweł initiated (bug 474358)
|
| 7 |
|
| 8 |
> The fact that this hasn't been done clearly implies it is a lot of |
| 9 |
> work. Let's not risk stable, let's simply make toolchain-r1.eclass or |
| 10 |
> whatever, and bump that to eapi5. At the end of the day, this allows |
| 11 |
> working and testing without odd issues, and if everyone really hates |
| 12 |
> that idea you can simply drop the changes into the original eclass |
| 13 |
> when it's all done. |
| 14 |
|
| 15 |
Having a unstable eclass as toolchain-r1.eclass in tree might not be a
|
| 16 |
good idea compared to an overlay though.
|
| 17 |
|
| 18 |
Regarding eclass, I have a question: Why do we keep all old versions of
|
| 19 |
gcc and glibc? If the point is only being upgradable from old Gentoo, is
|
| 20 |
the requirement lefted now? If it is for users who need a specific
|
| 21 |
version of gcc/glibc, why don't we create a toolchain-archive overlay
|
| 22 |
for that purpose? In the overlay we can have historical snapshots of
|
| 23 |
toolchain.eclass, too.
|
| 24 |
|
| 25 |
Keeping only a few version of gcc in tree will ease the maintenance of
|
| 26 |
toolchain eclass a lot.
|
| 27 |
|
| 28 |
Benda |
Archives