There are several ongoing problems with Perl stuff particularly around /usr/bin/ script installation. One present sore point is its not uncommon for the same 'bin-script' to be provisioned from multiple different ebuilds ( think: `corelist`, for example, shipped both by dev-lang/perl and perl-core/Module-CoreList ) Presently, we *only* deal with this situation in perl-core, where there's a half-working bodge that seemingly arbitrarily creates symlinks and makes fun binaries like "/usr/bin/corelist-5.202.6.20-perl-5.32.0" But this gets radically messed up when stuff moves from perl-core/* to dev-perl/, as we typically do when stuff gets "de-cored". This creates additional fun when a perl-core package gets 'pkgmove'd, as the moved *installed* package retains all the magic it did when it was in perl-core , but can go horribly wrong as a result (bug #675656) And additionally, extra fun is to be had if one dares install the dev-perl of a thing that was "previously core", on an older perl version that still ships that bin-script, as this inherently suggests a collision of some kind due to both shipping the same bin-script. And its really not obvious to me in any of the above situations what to expect "/usr/bin/<binscript>" to actually be ahead of time. Also, we have to think ahead to situations where we have multiple perls, with a matrix of "script X and its deps are supportable on perl Y", with a solution like python-exec. Subsequently, I'd like to investigate moving the binscripts to some path that I'll identify as GENTOO_PERL_BIN_ROOT, which could be: /usr/lib/perl/ With a layout that enumerates: - a token uniquely identifying the source gentoo package that provides the script which supports: - the same script being installed from multiple slots of the same package - the same script being installed from multiple package providers - a token uniquely identifying the target interpreter, supporting: - Installing the same script as an entry point for 1-or-more perl-compatible interpreters Any solution should have a tree-traversal dictated natural hierarchy when it comes to "multiple providers of the same script" Including, but not limited to: - dev-perl/ stuff comes first - perl-core/ stuff comes second - dev-lang/perl stuff comes last But with a provision for other things to properly shadow this in the right order (eg: for instance, gcpan-perl/ could install in its own path, in a position of its choosing, but I'd imagine it would want a higher precedence than dev-perl/) So this ultimately breaks down to GENTOO_PERL_BIN_ROOT/INTERPRETER/SOURCE/foo-bin As a start, I'd say the defacto value for INTERPRETER should be "perl-${SLOT}" Where competing implementations may get named "cperl-${SLOT}", etc. perhaps for SOURCE, our starting values should be: '05-cpan/${PN}-${SLOT}' For all things in dev-perl/, perl-core/, and gcpan-whatever (giving `/usr/lib/perl/perl-5.32/05-cpan/Dist-Zilla/dzil`) Stuff shipped by perl could be '50-perl/perl-${SLOT}` (giving `/usr/lib/perl/perl-5.32/50-perl/perl-5.32/corelist`) And yes, that is a bit redundant, and obviously, each of those paths would only exist inside their own INTERPRETER slot, and when there is only one value of INTERPRETER, the redundancy will naturally call cries from people who don't understand. But as soon as we have >1 concurrent INTERPRETER, all of this becomes necessary. Because the bin scripts that ship with perl 5.32 should not ever be run on the perl7 interpreter, only the bin scripts that ship with perl 7 should be run on the perl7 interpreter. Only cpan modules, which have been tried, and tested to work on >1 INTERPRETER, and have been explicitly configured in their relevant ebuilds to emit code for each interpreter, should have bin entry points for that interpreter, and subsequently, one can't "build dev-lang/perl:5.32 while also compiling all its support modules and bin scripts for dev-lang/perl:7.0" This situation gives you an end result of something like this: /usr/lib/perl/perl-5.32/05-cpan/Module-CoreList-0/corelist /usr/lib/perl/perl-5.32/50-perl/perl-5.32/corelist /usr/lib/perl/perl-7.0/05-cpan/Module-CoreList-0/corelist /usr/lib/perl/perl-7.0/50-perl/perl-7.0/corelist How exactly we do resolution of "some script" to either "a symlink in /usr/bin/" or "a symlink to a binary executable that does dispatch", is still something I need to think about. "Pick the right implementation for your interpreter" is the easy aspect. "Pick one from a bag of providers" is where I'm currently getting stuck, esp as seeing /usr/lib/perl/perl-5.32/05-cpan/Split-Module-0/corelist /usr/lib/perl/perl-5.32/05-cpan/Module-CoreList-0/corelist /usr/lib/perl/perl-5.32/05-cpan/Module-CoreList-1/corelist /usr/lib/perl/perl-5.32/50-perl/perl-5.32/corelist Is an entirely predictable situation to manage. (where we're currently only saved in some minor regard due to collision protection being a thing) The more I think of it, the more it seems sense to get rid of directory-indicated precedence, and have a preference file somewhere (or in the case of perl-exec, and ENV override) instead: /usr/lib/perl/perl-5.32/cpan/Split-Module/0/corelist /usr/lib/perl/perl-5.32/cpan/Module-CoreList/0/corelist /usr/lib/perl/perl-5.32/cpan/Module-CoreList/1/corelist /usr/lib/perl/perl-5.32/perl/perl/5.32/corelist Then one can have: INTERPRETERS="perl-7.0 perl-5.32" IMPLEMENTATION="cpan perl" Or the text files: > # /etc/config/perl/interpreters > # top most items take precedence > perl-7.0 > perl-5.32 > # /etc/config/perl/implementations > # top most items take precedence > cpan > perl Then, at a users discretion, the implementation list can be tweaked to > cpan/Module-CoreList/0 > cpan > perl Which would default "corelist" to resolve to cpan/Module-Corelist-0/corelist And everything else would by default resolve to "something in cpan/" first, and "something in perl/" second. One could argue that "perl/perl" is inherently redundant there, but without some hinky search logic, or special casing, its better than the alternatives. The "overshot" from the implementation-preference-order file is, feasibly, two packages could ship *two* binscripts, and you don't want the general implementation order to always apply (eg: you tweaked the order because you wanted X-impl of Y, but that inherently gave you X-impl of Z as well, and you wanted XX-impl of Z) So .... still open questions on how to best proceed with this. The especially hairy case is resolving the "best" default version when there are concurrent slots, a lexical ordering of: Module-CoreList-0 Module-CoreList-1 Defaults you to the older one, which is bad. Splitting it as Module-CoreList/0 and Module-CoreList/1 does allow the default-search-order mechanic to be lexical at the top level, and "largest numerically" at the second level without needing any special parsing. But handling "A/0" vs "B/1" with any sort of default search mechanism will have issues. ( And we really cant be expected to produce an ordered list of all bin-scripts in perlspace in order of "what should be used by default" ) Notedly, I'm waxing on about problems we currently don't have and can't have, due in part to the complete absence of slot concurrency in dev-perl and dev-lang/perl , and due in part to the relative rarity of upstream doing "splits" and relative rarity of multiple upstreams in the same ecosystem shipping the same bin script ( which when that happens, we bodge around the problem by renaming it in the ebuild )
> But handling "A/0" vs "B/1" with any sort of default search mechanism will have issues. ( And we really cant be expected to produce an ordered list of all bin-scripts in perlspace in order of "what should be used by default" ) NB: Obviously all of this should be instrumented with some sort of `eselect` stuff to facilitate a user changing from defaults, and to facilitate link/exec stuff being re-provisioned/reaped automatically, but having a default mechanism that works sensibly in absence of explicit user configuration is essential, and subsequently, working out what this default should look like is a precursor to any debate about how the eselect parts should work.
