Re: What am I doing wrong? A bad end-user experience
Ovid <[email protected]>
| Newsgroups | gmane.comp.lang.perl.perl5.porters |
|---|---|
| Message-ID | <CA+M4CHuvXX4xZTgwCSneO1k+ASfX27xt+=ydREcXnxufLfoW8Q@mail.gmail.com> |
On Thu, Sep 10, 2026 at 2:28 PM demerphq <[email protected]> wrote: > On Thu, 10 Sept 2026 at 13:49, Paul "LeoNerd" Evans < > [email protected]> wrote: > >> I keep a bunch of perl modules in my $HOME: >> >> $ env | grep PERL >> PERL5LIB=/home/leo/lib/perl5 >> PERL_MB_OPT=--install_base=/home/leo >> PERL_MM_OPT=INSTALL_BASE=/home/leo >> >> I use system perl. >> > > Yeah, well, that is where you go wrong. It is long and well established > that it is unwise to modify their system perl. Doing so is highly likely > to break your OS. > > Perl very well may be used in the OS'es build chain, and upgrading modules > can and will break things. > Would it be worth having cpan emit a non-fatal warning when an installation appears likely to affect the system Perl? I doubt we can do this reliably, but we can check $^X, Config’s site/vendor paths, whether local::lib or INSTALL_BASE is configured, package-manager ownership where available, and whether Module::CoreList identifies the module as core or dual-life. Probably many other things I don't know about. Blocking installation while waiting for user acknowledgement on VMs, containers and package-building systems would not be fun. Perhaps a suppressible warning, explaining that CPAN-installed modules may shadow vendor modules and affect OS tools? Maybe use that to explain the available alternatives? If people don't realize that changing system Perl is bad, or don't know there are alternatives, maybe we can give 'em a fighting chance to survive? Best, Ovid -- https://curtispoe.org/