On Mon, Apr 24, 2017 at 11:01:32AM -0500, William Hubbs wrote:
> 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.
> [...]
> > 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?

+1

> 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.

I would rather prefer to keep essential development tools in tree.
GCC is not only used as system compiler, but also for development.
I already had problems before with CMake being aggressively removed,
so I couldn't just install CMake 3.5.2 to test something that got
broken with the latest CMake (3.7.2 at the time).

For things like autotools, CMake, compilers, etc, I would like to
see at least the latest release of the previous major version (e.g.
CMake 2.8), and the last few latest releases from the current major
version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries,
as in prefix you may be somewhat limited by the host (think macOS),
so removing old ebuilds aggressively breaks stuff. I think this was
the case with clang before, where we needed 3.5 and that got removed,
so bootstrapping on macOS was broken for sometime.

Cheers,
—Guilherme


Reply via email to