Hi, TLDR: Skip to the ##TLDR marker below. We've just had another perl update and as always people with locally built perl modules ran into issues with random perl tools (including cpan) not working. I've looked into this back in 2014 already [1] and back then I chose to implement versioned dependencies to catch such issues. However I have not pushed for those dependencies to get adopted by AUR packages since doing so will force users to remove those packages prior to being able to update and the main goal was to detect incorrectly rebuilt packages in our repository (there were 3 from multiple maintainers IIRC). Naively I thought posting instructions to arch-dev-public on how to find broken modules would be sufficient. Turn out that not all users of the AUR read this list and some have unknowingly installed modules with cpan directly so even if they read the post, they wouldn't expect to have to run the check. ##TLDR Talking to some folks in #perl pointed me towards a hopefully satisfying solution. I plan to version the architecture specific directories and introduce a libalpm hook that checks for old directories and warns the user by printing a list of affected AUR/cpanplus-dist-arch packages, respectively a list of files for modules installed directly with cpan. The new directory layout would be "/usr/lib/perl5/$baseversion/{core,vendor,site}_perl" with $baseversion being "5.26" right now. Currently the layout is "/usr/lib/perl5/{core,vendor,site}_perl". The check for old versions would then be rather simple since it just has to look for directories beside the current version. During the old discussion, Justin raised the issue that if the directories are versioned, perl modules that are not rebuilt will just be missing. This could lead to software not detecting them any more and disabling a feature or using a slower module to do the job. One possibility to counter this would be to replace the perl executable with a wrapper that performs the check and prints errors to stderr. Optionally it could also exit with an error code rather than continuing to run the script. I'm not sure if I want this or not, but I'm leaning towards a yes since exiting will make the error more difficult to miss. If there are no objections I'll start working on this in the next couple of weeks. [1] https://lists.archlinux.org/pipermail/arch-dev-public/2014-June/026380.html Florian