Using CGI.pm is quite fine. It is still a CPAN module, and still supported by Debian. Moving to PSGI/Plack might be an option, but it is not at all compulsory. In Debian Wheezy, CGI.pm V3.52 is part of system Perl (5.14), and there's also a package libcgi-pm-perl for Wheezy with version 3.61. In Debian Jessie, there's no CGI in Perl 5.24, but there's still the Debian package libcgi-pm-perl, now version 4.35. You might need to install that package after upgrading.

If you use CGI qw(:standard), then there's not much to fear, it is just the :any tag which is no longer available. A notable change is that if you call the param() method in list context, you get a warning: So many programmers have been bitten by failing to do this correctly, so now you get the warning even if you know what you're doing. If you deliberately chose to call param() in list context, you can suppress this warning by setting $CGI::LIST_CONTEXT_WARN=0.

You need to do something if you used the internal module structure of the CGI package, e.g. the Fh package, which no longer exists, and you might eventually need to do something if you are using the CGI::Pretty module.

So, if the task at hand is upgrading from Wheezy to Stretch then I suggest to just go ahead and leave your CGI applications as they are.

Check the version of CGI.pm you're using. Read the change log forward from that version to go as far forward as possible without breaking your code (might be all the way to the current release) and then install whichever version seems best on the new servers. It's still just Perl and even if it's not core now, it's there for you to use in its many incarnations.

I would like to upgrade our servers OS from Wheezy to Debian Stretch which does not have CGI.pm in the Perl core. I believe the upgrade to Stretch will leave CGI.pm intact (which the scripts need), but if not, what do I do?

Debian Stretch should have a package containing CGI.pm. https://packages.debian.org/search?searchon=contents&keywords=%2FCGI.pm&mode=path&suite=stable&arch=any lists several packages containing a file named CGI.pm. libcgi-pm-perl seems to be the right one.

apt-get install libcgi-pm-perl
[download]

... and you have CGI.pm back, unfortunately the 4.x series that lacks proper upgrade information. Read the change log (/usr/share/doc/libcgi-pm-perl/changelog.Debian.gz and /usr/share/doc/libcgi-pm-perl/changelog.gz after package installation) in addition to the documentation. "CGI::param called in list context" confusion also contains useful information.

Alexander

CGI.pm ain't nothing but a pure-perl module

So replacing CGI.pm ain't nothing but busywork

As long as your .cgis are written well, that is as per CGI to mod_perl Porting. mod_perl Coding guidelines, then they're ready to run virtually unaltered in persistent environment thanks to PSGI

I agree to the extent that a CGI script that is ready to move to Apache::Registry is also ready to move to psgi via Plack::App::WrapCGI. I disagree that mod_perl should be recommended today. It RFC:SHOULD NOT be. We've been over the reasons this is the case, and has been for a decade, many times now.

I agree to the extent that a CGI script that is ready to move to Apache::Registry is also ready to move to psgi via Plack::App::WrapCGI.

As we should

I disagree that mod_perl should be recommended today.

I dont see that a particular persistent environment has been recommended. If you know of a better guide on fixing up cgi scripts you know what to do.

We've been over the reasons this is the case, and has been for a decade, many times now.

Not us we :)