| 1 |
On Mon, Apr 24, 2017 at 11:01:32AM -0500, William Hubbs wrote: |
| 2 |
> On Sun, Apr 23, 2017 at 02:35:48PM +0200, Michał Górny wrote: |
| 3 |
> > Hi, |
| 4 |
> > |
| 5 |
> > I'm thinking of masking old versions of sys-devel/gcc, in particular |
| 6 |
> > older than the 4.9 branch. |
| 7 |
> [...] |
| 8 |
> > My solution |
| 9 |
> > =========== |
| 10 |
> > |
| 11 |
> > I think there is no point in having explicit support for ancient gcc |
| 12 |
> > versions these days. However, I admit that some specific developers |
| 13 |
> > and users may have a need for them. Therefore, I think the best way |
| 14 |
> > forward would be to keep them in ::gentoo but p.mask with |
| 15 |
> > an explanatory message. |
| 16 |
> > |
| 17 |
> > The most important goal of having the packages masked is that it would |
| 18 |
> > cause Portage to verbosely complain whenever the users have it |
| 19 |
> > installed. With appropriate comment (displayed by Portage), we could |
| 20 |
> > clearly inform users that they need to upgrade gcc and switch to a new |
| 21 |
> > version to ensure that majority of packages work. |
| 22 |
> > |
| 23 |
> > We would also clearly indicate that we no longer support the old |
| 24 |
> > versions and do not have to explicitly indicate this non-support via |
| 25 |
> > explicit version checks in ebuilds. |
| 26 |
> > |
| 27 |
> > At the same time, users who really need those versions could unmask them |
| 28 |
> > on their own responsibility and knowing the implications of setting them |
| 29 |
> > as system-wide compilers. |
| 30 |
> > |
| 31 |
> > |
| 32 |
> > What do you think? |
| 33 |
|
| 34 |
+1 |
| 35 |
|
| 36 |
> Honestly, |
| 37 |
> |
| 38 |
> if we aren't going to officially support those older versions of gcc, I |
| 39 |
> would rather see them moved to an overlay and removed from the main |
| 40 |
> tree. |
| 41 |
|
| 42 |
I would rather prefer to keep essential development tools in tree. |
| 43 |
GCC is not only used as system compiler, but also for development. |
| 44 |
I already had problems before with CMake being aggressively removed, |
| 45 |
so I couldn't just install CMake 3.5.2 to test something that got |
| 46 |
broken with the latest CMake (3.7.2 at the time). |
| 47 |
|
| 48 |
For things like autotools, CMake, compilers, etc, I would like to |
| 49 |
see at least the latest release of the previous major version (e.g. |
| 50 |
CMake 2.8), and the last few latest releases from the current major |
| 51 |
version (e.g. CMake 3.{5,6,7}). Similarly for essential libraries, |
| 52 |
as in prefix you may be somewhat limited by the host (think macOS), |
| 53 |
so removing old ebuilds aggressively breaks stuff. I think this was |
| 54 |
the case with clang before, where we needed 3.5 and that got removed, |
| 55 |
so bootstrapping on macOS was broken for sometime. |
| 56 |
|
| 57 |
Cheers, |
| 58 |
—Guilherme |
Archives