Re: pkgsrc freeze for 2016Q4 starting on Dec 19

[coypu%SDF.ORG@localhost]

On Thu, Dec 15, 2016 at 11:31:35PM +0100, Joerg Sonnenberger wrote:
> Can we sit down and start pruning some things then? E.g. we have way too
> many LibreOffice and OpenOffice versions in the tree, I think. Given how
> heavy those packages are, that's a lot of build time.
> 

Figured I should mention it here as well:

We could prune some of the GCC versions,
specifically the GCC 4.x versions.
The various versions remain in use due to our
GCC_REQD passing specific versions.

A main motivation is the maintenance burden.
We will continue to see issues with the GCC
packages.
- Debian put CRT stuff in
 /usr/lib/x86_64-linux-gnu, so the build
 breaks. Someone(TM) should figure out how
 to patch this in. Needed for having a
 working pkgsrc fortran.
- New compilers break the build (less
 of an issue)
- NetBSD/not-x86 is still unable to build
 any pkgsrc GCC (I've tested MIPS & ARM).

It carries an additional benefit for users. We can
resolve all GCC_REQD+=4.6 and point at 4.9 if the
builtin compiler is not higher than 4.6, so fewer
compilers will have to be built.*

Whichi GCC 4.x versions are worth keeping:
- GCC 4.2, which we surprisingly don't have.
it's the last GPLv2 version and some people have
an interest in that.

- One of the later ones, like GCC 4.9 or 4.8.
The inbetween ones have various incompleteness
of C++11 support, which is the usual cause for
requiring pkgsrc GCC.

- Having a version that matches a NetBSD release
makes it easier to pull in patches, so that's a
second option (they are: 5.4.0, 4.8.4, 4.5.3).
Having a match to a NetBSD release's GCC for
gfortran is also beneficial to reduce the
mismatch in libraries.

jperkin@ being the heaviest user of pkgsrc GCC
should probably mention his favourite. I think
it's 4.9 that he likes, as 4.8 has a lot of
extra patches.

Certainly gcc44, gcc45, gcc46, gcc47 can go.

There's some chance we have a user that can
build gcc45 but not later, but it would be
easier to tackle that problem once we confirm
it actually exists, and with fewer versions
to fix things in.

NetBSD's base builder currently builds GCC
5.4.0 with GCC 4.5.3, so it's less likely to
be a problem than one would imagine.

* Insert joerg mention of how building one
package which built its dependencies with
two libstdc++s is expected to break in
surprising ways.