From: Guilherme Amadio <amadio@gentoo.org>
To: gentoo-dev@lists.gentoo.org, mgorny@gentoo.org
Subject: Re: [gentoo-dev] RFC: masking old versions of sys-devel/gcc
Date: Mon, 24 Apr 2017 19:59:53 +0200 [thread overview]
Message-ID: <20170424175952.GA5202@gentoo.org> (raw)
In-Reply-To: <20170424160132.GA4479@whubbs1.gaikai.biz>
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
next prev parent reply other threads:[~2017-04-24 18:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-23 12:35 [gentoo-dev] RFC: masking old versions of sys-devel/gcc Michał Górny
2017-04-24 16:01 ` William Hubbs
2017-04-24 17:59 ` Guilherme Amadio [this message]
2017-04-25 16:26 ` William Hubbs
2017-04-25 16:44 ` Guilherme Amadio
2017-04-25 18:38 ` Francesco Riosa
2017-04-25 22:26 ` Andreas K. Huettel
2017-04-26 0:37 ` Francesco Riosa
2017-04-26 9:32 ` Andreas K. Huettel
2017-04-26 14:59 ` Mike Gilbert
2017-04-27 2:08 ` Walter Dnes
2017-04-27 15:27 ` William Hubbs
2017-04-27 22:56 ` Andrew Savchenko
2017-04-26 9:42 ` Chí-Thanh Christopher Nguyễn
2017-04-26 12:22 ` Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170424175952.GA5202@gentoo.org \
--to=amadio@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=mgorny@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox