Apple "macOS Catalina 10.15 Release Notes":
Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
So we will need to distribute our own perl interpretter with fink. Two options I can envision are:
- Distribute the actual perlXXX binary contents in fink-....tar.gz, and then copy it into place as part of bootstrap process (the contents of perlXXX being part of the 'fink' package, or eventually getting overwritten by an Essential perlXXX package).
- Distribute a private perl binary in fink-....tar.gz for bootstrap purposes, sufficient to get fink running long enough to build an actual "perlXXX" package and then relaunch using it.
- Include the perlXXX source (or a download mechanism for it) in fink-....tar.gz and build it ASAP
The ./boostrap script is itself a perl program, so if we don't include a perl binary we need a new shell wrapper around ./bootstrap that builds a perl ASAP. Perl includes some hardcoding of its runtime path, so a perl binary included in the fink tarball might need to be patched by a script to be runnable enough for ./bootstrap and again if we use it as-is to copy into the live fink world.
If we have a new shell-language bootstrap wrapper that builds a perl from source, that avoids the relocation issue of where the fink tarball is unpacked, but would mean we build perl itself twice.
According to ./bootstrap comments and git history, we had once previously had fink use its own perl: when running on 10.5 with arch=x86_64 rather than the default i386 on that platform, fink ran using its own perl588 that was built by the bootstrap process (and there was a separate perl588-bootstrap package for it similar to dpkg-bootstrap). So if we included a prebuilt perl binary, we could use it to run ./bootstrap and have perlXXX-bootstrap simply copy it, then have an actual perlXXX source package that gets built.
Another issue is how to handle perl versioning. Last I knew, all packages that are runtime dependencies of Essential:true packages must themselves be Essential:true. That means some blessed perlXXX-core becomes Essential:true unless we want to have fink contain a private-subdir'ed perl in fink.deb solely for its own scripts. I recall some difficulty with making a package that had existed as Essential:true no longer essential (it became a bit immortal somehow). If we have a private perl, then we could have fink use compiled (binary) perlmods from CPAN, something we cannot currently do because they can break when the perl version changes. And somehow we probably should have a guaranteed non-perlversioned path to a perl interp in PATH so we don't have to perlversion every damn script.
Apple "macOS Catalina 10.15 Release Notes":
So we will need to distribute our own perl interpretter with fink. Two options I can envision are:
The ./boostrap script is itself a perl program, so if we don't include a perl binary we need a new shell wrapper around ./bootstrap that builds a perl ASAP. Perl includes some hardcoding of its runtime path, so a perl binary included in the fink tarball might need to be patched by a script to be runnable enough for ./bootstrap and again if we use it as-is to copy into the live fink world.
If we have a new shell-language bootstrap wrapper that builds a perl from source, that avoids the relocation issue of where the fink tarball is unpacked, but would mean we build perl itself twice.
According to ./bootstrap comments and git history, we had once previously had fink use its own perl: when running on 10.5 with arch=x86_64 rather than the default i386 on that platform, fink ran using its own perl588 that was built by the bootstrap process (and there was a separate perl588-bootstrap package for it similar to dpkg-bootstrap). So if we included a prebuilt perl binary, we could use it to run ./bootstrap and have perlXXX-bootstrap simply copy it, then have an actual perlXXX source package that gets built.
Another issue is how to handle perl versioning. Last I knew, all packages that are runtime dependencies of Essential:true packages must themselves be Essential:true. That means some blessed perlXXX-core becomes Essential:true unless we want to have fink contain a private-subdir'ed perl in fink.deb solely for its own scripts. I recall some difficulty with making a package that had existed as Essential:true no longer essential (it became a bit immortal somehow). If we have a private perl, then we could have fink use compiled (binary) perlmods from CPAN, something we cannot currently do because they can break when the perl version changes. And somehow we probably should have a guaranteed non-perlversioned path to a perl interp in PATH so we don't have to perlversion every damn script.