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