This may be as intended/expected, but... Prior perl 5.x.0 releases created /usr/lib64/perl5/5.x.0/ and .../vendor/5.x.0/ dirs, which corresponds to $Config{version}. The perl-5.32.0-r1 that got unmasked yesterday results in: # ls -ld /usr/lib64/perl5/{,*/}5* drwxr-xr-x 54 root root 4096 Jan 2 15:24 /usr/lib64/perl5/5.32 drwxr-xr-x 74 root root 4096 Jan 2 17:26 /usr/lib64/perl5/vendor_perl/5.32 And yet: # perl -MConfig -e 'print "$Config{version}\n";' 5.32.0 I don't know if this is a difference in upstream or in the new ebuild, nor do I know if it was intentional and for good reason. I only know it was a surprise when I had some things that thought for years that $Config{version} was safe to use to derive appropriate dirs, and that turned out to not work any more.
It's intentional and from this end, result of this commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8bd62e2d2765dccebcbb5af5bdd25dab75a28cc8 I personally don't see a problem with it so far other than perl-cleaner being confused.
This is intentional, in part, because there are complicated problems when it comes to release engineering with the existing strategy of "just reuse the directories that already exist", when you start dealing with binpkgs. Namely, if you install a clean 5.x.1, build a binpkg for it, and then later, install a clean 5.x.2 on a different machine, that binpkg *cannot* work on it due to the path names in @INC being mutually exclusive. Using $Config{version} directly is generally not advised, even though it does work. One should use a specific entry such as: $Config{sitearchexp}, $Config{archlibexp} $Config{vendorarchexp} etc. If you're doing this from within ebuilds, there are helpers in perl-functions.eclass dedicated to getting the useful values out.
The canonical description for the intentional changes is in this commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-lang/perl?id=80bf6a8420ffc005391f048f093679ac417bf5c5 Been a work in progress for a while.
Ah, so it was indeed intentional. OK cool, thanks. I had not thought that it was safe to assume perl modules would always be compatible across .z patchlevel, but I guess so, and now that I look, see distros like debian doing only x.y as well. At least I am in good company being initially surprised, because it seems perl-cleaner is also confused (https://bugs.gentoo.org/763021). I'll adjust to the new world order on my side, thanks!
