On Sun, Apr 23, 2017 at 02:35:48PM +0200, Michał Górny wrote:
> 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?

Honestly,

if we aren't going to officially support those older versions of gcc, I
would rather see them moved to an overlay and removed from the main
tree.

Yes, some users and developers may need them for some obscure purpose,
but that doesn't justify keeping them permanently masked in the main
tree especially since package.mask isn't supposed to be a permanent
thing.

There is a ::toolchain overlay somewhere, maybe they should go there
instead of in the main tree.

Thanks,

William