Virtual package to check whether gfortran compiler installed from non-Fink source (e.g. the HPC distributions). Modeled on system-fortran package that checks for Absoft Fortran compiler.
dpkg -L output
A problem with this idea is that most (not all, admittedly) packages that use, say, gfortran from gcc47 also link to its libgfortran library.
If I understand the comment properly, this is no more or less of a problem than was presented by system-fortran and the Absoft compiler case. If you upgrade your non-Fink compiler, you may break Fink-compiled packages.
On the other hand, the user already is reporting use of a non-Fink component, so should be prepared to cope with the consequences of doing so. It is a general problem upgrading any compiler -- changes to runtime libraries may break dynamically linked object code, but responsible maintainers try to retain reverse compability through minor releases. This includes gfortran.
My recollection is that linking to an internal library wasn't an issue with the standalone Fortran compilers of that era: f77, g95, etc.
My comment wasn't about upgrades. It's about the fact that your proposed system-gfortran is _not_ drop-in compatible with the gfortran from e.g. gcc47, except for those few packages which just need _a_ fortran compiler and don't link to libgfortran. It's not drop-in compatible because if you remove the third-party gfortran, you can't just install a Fink alternative and have things work without a rebuild. This would mean that to use the system-gfortran package, most packages would require an additional variant.
It seems to me that the present Fink dependency mechanism handles this situation. If somebody tries to remove the system-gfortran package, then any package built with it will prevent it from being removed. Once these are removed, then either a Fink Fortran offering or a new/different system-gfortran will allow the dependent packages to be rebuilt on the replacement Fortran, whatever its source.
To me, it seems unrealistic for a Fink user to expect that Fink can provide a drop-in replacement for the runtime support of any old system-gfortran. Perhaps a suitable use caveat could be put in the virtual package to forestall any expectation. Any suggestion to make this palatable?
So we agree: this isn't a drop-in replacement. So then I don't see the point of the package.
Almost every package which uses gfortran would have to have a _new_ variant to use this system-gfortran. There's no either/or with this and a Fink's gcc4N possible.
Rather, it would be *categorically against our library policy* to try to have e.g. system-gfortran | gcc47 in the BuildDepends.
To help see the point of this package, consider the situation many Mac-based Fortran programmers find themselves in. To use Fortran they have an option to install Fink's gccX suite that gives them more than just gfortran. They also have an option to go and download Fortran-only compilers from many possible sources. My own Fortran is not Fink's and neither is anybody else's in my research group or department.
So, if I want to package something and distribute it through Fink, none of my research group or department members will use it unless they can avoid having to forfeit their Fortran. This gives them a way to avoid doing so, thereby increasing the Fink user community.
I'm certainly willing to package software to use Fink's gccX suite, but my local institutional uptake will be nil -- a pity for all.
Here's a counterpoint: almost no _existing_ package in Fink can use this.
Because it's not drop-in compatible at all from a library standpoint, maintainers of libgfortran-linking packages would have to decide for themselves if it's worth the additional effort to provide a variant to support system-gfortran. Or others could provide these variants. This would entail:
1) A new package name, because "fink rebuild" is not deemed to be an acceptable way to switch between incompatible dependencies.
2) Changing environment variables and scripts around not to use Fink's gcc4N paths.
3) Not running the "fink-package-precedence" test script, because that explicitly returns a failure for the use of items in /usr/local.
2) and 3) can entail either using a lot of conditional structures or a new .info file.
Basically I'm just trying to manage expectations.