Hi,

I'm thinking of masking old versions of sys-devel/gcc, in particular
older than the 4.9 branch.


The problem
===========

Gentoo users still sometimes try to build new packages with old gcc
versions which inevitably fails, either due to bugs or missing features
in the old versions of gcc. The most relevant example is C++ packages
requiring support for C++11 which is obviously missing from old gcc
versions.

I think this mostly affects old installations where sysadmins fail to
update and/or switch gcc before starting system upgrades. While I don't
think it's a major issue anymore, some developers still try to make
their ebuilds more complex to account for that.

Most of the time fixing the support for old gcc is out of the question.
In that case, developers add checks for appropriately new gcc version
(which may randomly fail with clang) and/or features. While this solves
the immediate problem, it causes unnecessary complexity. With EAPI 5,
the proper way of checking this involves running pkg_pretend() -- which
causes a major slowdown for the package manager.

Nowadays a great number of packages requires C++11. Adding pkg_pretend()
check for every single one of them is both a lot of work
and a significant slowdown to support outdated systems. Or rather, to
replace a error from the build system with early error from ebuild.
Worse than that, developers sometimes deploy different kinds of checks,
some of which are buggy.


My solution
===========

I think there is no point in having explicit support for ancient gcc
versions these days. However, I admit that some specific developers
and users may have a need for them. Therefore, I think the best way
forward would be to keep them in ::gentoo but p.mask with
an explanatory message.

The most important goal of having the packages masked is that it would
cause Portage to verbosely complain whenever the users have it
installed. With appropriate comment (displayed by Portage), we could
clearly inform users that they need to upgrade gcc and switch to a new
version to ensure that majority of packages work.

We would also clearly indicate that we no longer support the old
versions and do not have to explicitly indicate this non-support via
explicit version checks in ebuilds.

At the same time, users who really need those versions could unmask them
on their own responsibility and knowing the implications of setting them
as system-wide compilers.


What do you think?

-- 
Best regards,
Michał Górny