Re: *more* relocatable perl

[email protected] (Dan) Sat, 18 Jul 2026 19:13:50 -0400
Newsgroups perl.perl5.porters
Message-ID <CABMkAVVfFEbJuxFmBgo0zBa4YUF9pDVwJO4DiswabJ_Pi93GtQ@mail.gmail.com>
--0000000000003220270656ead492
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 18, 2026 at 6:36=E2=80=AFPM Darren Duncan <darren@darrenduncan.=
net>
wrote:

> On 2026-07-18 2:15 p.m., Gianni Ceccarelli via perl5-porters wrote:
> > On 2026-07-18 Darren Duncan <[email protected]> wrote:
> >> As long as the user knows where the "main program" is and invokes
> >> that, it can find all of its other pieces and dependencies relative
> >> to its own location implicitly without having to be fed any extra
> >> parameters and without any recompilation
> >
> > Yep! Exactly that.
> >
> > And a perl built with `userelocatableinc` is *very close* to that,
> > except for a handful of %Config entries.
> That leaves me to question why the behavior of userelocatableinc is not
> the
> default, what are its downsides that it isn't simply how perl always
> works. --
> Darren Duncan
>

A necessity of being relocatable is relative paths, which are a security
nightmare.

-Dan

--0000000000003220270656ead492
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare=
nt">On Sat, Jul 18, 2026 at 6:36=E2=80=AFPM Darren Duncan &lt;<a href=3D"ma=
ilto:[email protected]">[email protected]</a>&gt; wrote:</span>=
</div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">On 2026-07-18 2:15 p.m., Gianni Ceccarelli vi=
a perl5-porters wrote:<br>
&gt; On 2026-07-18 Darren Duncan &lt;<a href=3D"mailto:darren@darrenduncan.=
net" target=3D"_blank">[email protected]</a>&gt; wrote:<br>
&gt;&gt; As long as the user knows where the &quot;main program&quot; is an=
d invokes<br>
&gt;&gt; that, it can find all of its other pieces and dependencies relativ=
e<br>
&gt;&gt; to its own location implicitly without having to be fed any extra<=
br>
&gt;&gt; parameters and without any recompilation<br>
&gt; <br>
&gt; Yep! Exactly that.<br>
&gt; <br>
&gt; And a perl built with `userelocatableinc` is *very close* to that,<br>
&gt; except for a handful of %Config entries.<br>
That leaves me to question why the behavior of userelocatableinc is not the=
 <br>
default, what are its downsides that it isn&#39;t simply how perl always wo=
rks. -- <br>
Darren Duncan<br></blockquote><div><br></div><div>A necessity of being relo=
catable is relative paths, which are a security nightmare.</div><div><br></=
div><div>-Dan=C2=A0</div></div></div>

--0000000000003220270656ead492--