gcc5 migration tracker

[dmacks]

We're up to gcc9 now, and apple keeps making changes that break things (see #359 and #470). Let's think about migrating packages that still use older gccX to later ones and reduce the amount of old stuff we have to support (or other packages that wind up unavailable as reverse-(build)depends of them).

1. It looks like r-baseXX propagates the gcc that was used to build it into a BDep for all rmods built to use it, so we'd need a flag-day where we rev-up everything all at once if we migrate any of r-base{31,32,32,34,35} to a newer gccX. However, with r-base36 about to land (#471) with gcc9, we could have -r36 use that. And maybe mask older r-baseXX (and their -rXX mods) out of the later OS X distros (there already are Distribution: tags but they are all obsolete and functionally no-ops).
2. Octave also has some gccX dependencies that might need to remain synchronized. But a bunch of *-octXXX have Type:gcc that aren't used at all so maybe that would be a sepate cleanup task.
3. Here are the other gcc5 reverse-(build)depends I see by a quick grep:
   • Maintainer: Pierre-Henri Lavigne
   • [x] adonthell
   • [x] wastesedge
   • Maintainer: Jack Fink
   • [x] freedroidrpg
   • [x] mathgl6
   • Maintainer: Hanspeter Niederstrasser
   • [x] gmic
   • [x] xcrysden
   • Maintainer: Daniel Macks
   • [x] pdftk - currently needs gcj, which is gccX<=5 only. Masked to dist<<10.15
   • Maintainer: W. G. Scott (#561)
   • [x] clipper
   • [x] coot
   • [x] libccp4
   • [x] phaser-mpi
   • [x] refmac
   • [x] tinker
   • [x] usf
   • Maintainer: Martin Costabel (#546 and #569)
   • [x] ddscat
   • [x] harminv
   • [x] libctl
   • [x] meep
   • [x] melina
   • [x] modulef
   • Maintainer: Remi Mommsen (#496)
   • [x] geant4.9
   • [x] oot-pythia
   • [x] root5
   • Maintainer: Kurt Schwehr
   • [x] hdf
   • [x] sioseis
   • Maintainer: Aurelien Chanudet
   • [x] mpb
   • Maintainer: Sylvain Barbot
   • [x] relax (#658)
   • Maintainer: Alexander Hansen
   • [x] libnc-dap3
   • [x] qrupdate
   • [x] xraylib3-gfortran
   • Remkoo Scharroo
   • [x] lapack350 (#483 and akh's qrupdate are the only rdep of this old lapack libversion)
   • [x] lapack360 (akh's gracegtk, which is also tracked in #482 as a gcc6 user) is the only dep of this old lapack libversion)
   • Maintainer: none
   • [x] apbs
   • [x] atlas
   • [x] fftw
   • [x] hdf5 (suite of related libs)
   • [x] cfitsio
   • [x] gildas
   • [x] slatec
   • [x] sundials
   • Maintainer: BABA Yoshihiko
   • [x] r-base36
   • [x] r-base31 to r-base35 (gccX propagates to any rmod using gfortran)

[nieder]

Also, note that gcc9 is the only gccX package that builds on 10.15, and I don't expect gcc5-gcc8 to be 10.15 capable anytime soon.

[nieder]

Bringing in owners of the above that I know: @x-ii-ii-x @mringwal @smaret @wgscott @costabel @mommsen @remkos @akhansen

[nieder]

@babayoshihiko With r-base36 now in git, should we restrict r-base33/34/35 to 10.9-10.14.5 so that we don't have to worry about updating them to gcc9 to be able to do 10.15? r-base31/32 are already restricted to 10.9-10.12.

[babayoshihiko]

@nieder

@babayoshihiko With r-base36 now in git, should we restrict r-base33/34/35 to 10.9-10.14.5 so that we don't have to worry about updating them to gcc9 to be able to do 10.15? r-base31/32 are already restricted to 10.9-10.12. The results is this?:

Distribution: << (%type_pkg[rversion] = 31 ) 10.9, (%type_pkg[rversion] = 31 ) 10.10, (%type_pkg[rversion] = 31 ) 10.11, (%type_pkg[rversion] = 31 ) 10.12, (%type_pkg[rversion] = 32 ) 10.9, (%type_pkg[rversion] = 32 ) 10.10, (%type_pkg[rversion] = 32 ) 10.11, (%type_pkg[rversion] = 32 ) 10.12 (%type_pkg[rversion] = 33 ) 10.9, (%type_pkg[rversion] = 33 ) 10.10, (%type_pkg[rversion] = 33 ) 10.11, (%type_pkg[rversion] = 33 ) 10.12, (%type_pkg[rversion] = 33 ) 10.13, (%type_pkg[rversion] = 33 ) 10.14, (%type_pkg[rversion] = 34 ) 10.9, (%type_pkg[rversion] = 34 ) 10.10, (%type_pkg[rversion] = 34 ) 10.11, (%type_pkg[rversion] = 34 ) 10.12, (%type_pkg[rversion] = 34 ) 10.13, (%type_pkg[rversion] = 34 ) 10.14, (%type_pkg[rversion] = 35 ) 10.9, (%type_pkg[rversion] = 35 ) 10.10, (%type_pkg[rversion] = 35 ) 10.11, (%type_pkg[rversion] = 35 ) 10.12, (%type_pkg[rversion] = 35 ) 10.13, (%type_pkg[rversion] = 35 ) 10.14 <<

[nieder]

@babayoshihiko yes, except we would need to add the 10.14.5 distribution as well. It's very unwieldly and we would need to add it to every rmod. Thoughts?

[dmacks]

I'm going to work on our pile of lapackXXX libs

[nieder]

@schwehr 's hdf package works with gcc9 and dx (only dependee) works. There's also a much newer version 4.2.13 that dx also seems to be OK with. Should we bump %v for hdf when doing the gcc9 bump?

[dmacks]

pdftk uses gcj, which fink's gccX stopped supplying after gcc5.

[mringwal]

@dmacks Thanks for checking. pdftk has been tricky to build (trying to compile java to native instead of just providing a java command line tool hasn't been a good idea in the first place) and I'm not motivated to work on it.

I'd suggest to remove the package all together (unless someone would like to maintain it).

[dmacks]

I can support (well, life-support) pdftk rather than see it deleted, since it's part of one of my workflows on some machines that are being held back at 10.13/10.14 for the forseeable future.

[mringwal]

@dmacks I'd be glad if you take over pdftk.

I've stumbled upon a java port of pftk - which is/was written in Java in the first place.

The other option is the also old, but probably compilable PDFKitTool

[dmacks]

Thanks for finding those. I'll hang onto pdftk as long as I need it, but obviously we'd welcome any other new packages that are actually buildable on modern OS and don't do weird and fragile coding things:)

[nieder]

I think this is finished. The last holdovers were pdftk and r-base35 and down (plus all rmods). Those have been dist restricted. Anything left?

[cooljeanius]

I think this is finished. The last holdovers were pdftk and r-base35 and down (plus all rmods). Those have been dist restricted. Anything left?

I think that this can be closed now.