Re: *more* relocatable perl
Dan <[email protected]> Sat, 18 Jul 2026 19:13:50 -0400
| Newsgroups | gmane.comp.lang.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 <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> 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> > On 2026-07-18 Darren Duncan <<a href=3D"mailto:darren@darrenduncan.= net" target=3D"_blank">[email protected]</a>> wrote:<br> >> As long as the user knows where the "main program" is an= d invokes<br> >> that, it can find all of its other pieces and dependencies relativ= e<br> >> to its own location implicitly without having to be fed any extra<= br> >> parameters and without any recompilation<br> > <br> > Yep! Exactly that.<br> > <br> > And a perl built with `userelocatableinc` is *very close* to that,<br> > 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'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--