1 |
Hi, |
2 |
|
3 |
I'm thinking of masking old versions of sys-devel/gcc, in particular |
4 |
older than the 4.9 branch. |
5 |
|
6 |
|
7 |
The problem |
8 |
=========== |
9 |
|
10 |
Gentoo users still sometimes try to build new packages with old gcc |
11 |
versions which inevitably fails, either due to bugs or missing features |
12 |
in the old versions of gcc. The most relevant example is C++ packages |
13 |
requiring support for C++11 which is obviously missing from old gcc |
14 |
versions. |
15 |
|
16 |
I think this mostly affects old installations where sysadmins fail to |
17 |
update and/or switch gcc before starting system upgrades. While I don't |
18 |
think it's a major issue anymore, some developers still try to make |
19 |
their ebuilds more complex to account for that. |
20 |
|
21 |
Most of the time fixing the support for old gcc is out of the question. |
22 |
In that case, developers add checks for appropriately new gcc version |
23 |
(which may randomly fail with clang) and/or features. While this solves |
24 |
the immediate problem, it causes unnecessary complexity. With EAPI 5, |
25 |
the proper way of checking this involves running pkg_pretend() -- which |
26 |
causes a major slowdown for the package manager. |
27 |
|
28 |
Nowadays a great number of packages requires C++11. Adding pkg_pretend() |
29 |
check for every single one of them is both a lot of work |
30 |
and a significant slowdown to support outdated systems. Or rather, to |
31 |
replace a error from the build system with early error from ebuild. |
32 |
Worse than that, developers sometimes deploy different kinds of checks, |
33 |
some of which are buggy. |
34 |
|
35 |
|
36 |
My solution |
37 |
=========== |
38 |
|
39 |
I think there is no point in having explicit support for ancient gcc |
40 |
versions these days. However, I admit that some specific developers |
41 |
and users may have a need for them. Therefore, I think the best way |
42 |
forward would be to keep them in ::gentoo but p.mask with |
43 |
an explanatory message. |
44 |
|
45 |
The most important goal of having the packages masked is that it would |
46 |
cause Portage to verbosely complain whenever the users have it |
47 |
installed. With appropriate comment (displayed by Portage), we could |
48 |
clearly inform users that they need to upgrade gcc and switch to a new |
49 |
version to ensure that majority of packages work. |
50 |
|
51 |
We would also clearly indicate that we no longer support the old |
52 |
versions and do not have to explicitly indicate this non-support via |
53 |
explicit version checks in ebuilds. |
54 |
|
55 |
At the same time, users who really need those versions could unmask them |
56 |
on their own responsibility and knowing the implications of setting them |
57 |
as system-wide compilers. |
58 |
|
59 |
|
60 |
What do you think? |
61 |
|
62 |
-- |
63 |
Best regards, |
64 |
Michał Górny |