There are modules which are purely core and there are modules which are dual-life. The latter should be fine to upgrade - I've done it in the past with Time::Piece and with CGI (when that was in core) without problems. You can (and should) check the test matrix before starting to see how the upgraded version plays with your perl version and architecture.

OTOH if you are talking about modules which are only in core then I would have to ask why you would want to do this. You are going to have to go out of your way to obtain the source and then install it and then hope it works and if it doesn't, hope that you can roll back. It seems like a lot of effort and jeopardy for little reward.

There are modules which are purely core and there are modules which are dual-life. The latter should be fine to upgrade

How can one tell if a core module is purely core or dual-life?

I would have to ask why you would want to do this.

I don't want to do it, I'm just wondering how to handle it in a custom cpan client.

If you search on CPAN and find a module which also has its own distribution as well as being in the "perl" distribution then that is dual-life. There's also a handy list on github.

If you are writing a custom CPAN client then I would suggest you simply ignore this. Dual-life modules should be treated by the client just the same as anything else on CPAN. Purely core modules shouldn't be updated by the client. Simple.

---

🦛

"How can one tell if a core module is purely core or dual-life?"

Take a look at a post of mine from last week which discusses this. It has other information, and does not use the term "dual-life". See the two sections which start with:

• "Modules which are core, but do not have a separate CPAN version, ..." [i.e. purely core]
• "Modules which are core, but also have a separate CPAN version, ..." [i.e. dual-life]

— Ken

The normal expectation is that if a later version of the module uses new features of perl, it will set the required version of perl accordingly. If it uses new features in a module, it will set the required version of that module appropriately.

Core modules generally tend to get more testing and more review than non-core modules, so in the general case I would expect upgrading dual-life core modules to be less dangerous than upgrading non-core modules (assuming you install them only if the tests pass). That said, neither review systems nor code are ever perfect, there will always be some risk of breakage - it's always good to have a plan for how to back out a change.

If "upgrade" means: Install a new version from CPAN, then you should be safe. If a core module is available on CPAN, then this is exactly why: so that you can upgrade it without upgrading Perl.

The details vary between different platforms, but there are safeguards in place:

• Core modules come with a decent set of tests. Run them, as one usually does when installing from CPAN. If one of the test fails, then the module refuses to install - no harm done.
• Modules installed from CPAN end up in other directories (with higher priorities in @INC) than those coming with the core. So you don't overwrite existing files. Just keep track where the files go so that you can backpedal if desired.

Mostly, this also applies to XS modules. If you install them from CPAN, they will be compiled and tested against your installed version of Perl, and end up in a directory specific for your version, but still different from the directory where you got it with Perl. The rollback is a bit more complex because more than one directory needs to be "cleaned".

An old module could use deprecated features which won't work. It could also explicitly require a newer Perl version.

So you need to try it out and that - strongly recommend - with a plan to roll back in case it fails

Better don't overwrite the core module but try installing the new one into a separate path which you prepend globally to @INC in the sites config.

Never tried this though ... here are dragons.