develooper Front page | perl.perl5.porters | Postings from March 2023

Re: Managing Perl installations

Thread Previous | Thread Next
From:
demerphq
Date:
March 8, 2023 13:30
Subject:
Re: Managing Perl installations
Message ID:
CANgJU+Vqs6N-GwV7KDxpH1nYJTd_Gmxh5yR0WZB74wf5ckRzcQ@mail.gmail.com
On Wed, 8 Mar 2023 at 14:19, demerphq <demerphq@gmail.com> wrote:
> > If we look at it from the standpoint of my user story, I think core should be involved because I want to download and install Perl and already have the primary tool necessary to implement that story.
>
> So i /think/ what you mean by that is you want to download and install
> perl in a way that we do not currently really support out of the box.
> Not as a generic site wide installation on the computer in question,
> but as an application specific installation which should have no
> exposure to any other application or software installed on the box.

I was trying to think about "what would be different for an
application perl and a site-wide perl", and here is what i came up
with:

1. In an application perl most of the environment variables understood
by perl should *not* randomly come from the environment. They should
probably come from a specific configuration file which is private to
and owned by the application only.
2. In an application perl none of the libraries should come "from the
perl" they should come from the application itself.  There should be
no "site_perl" directory, nor "lib" directory built in. CPAN should
never install modules into the perls trees, and should not even be
usable with it. (Modulo maybe modules required to implement internal
features of that perl, for instance the NamedCapture ties that we used
to have implemented as perl modules)
3. There should be no perlbug or other utilities installed with the
perl except those that come with the application.
4. All features where a perl knows to execute another perl should be
disabled. If an application is intended to be run against a specific
perl executable that perl executable shouldnt be tricked into spawning
another perl.
5. Features like taint, and whatnot should be compiled out, or in,
depending on the applications needs.

This isnt an exhaustive list btw, just trying to think this through.
yves

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About