in reply to Re^3: RFC: (Do Not) Modify the System Perl
in thread RFC: (Do Not) Modify the System Perl

I wonder why you kick up such a shindy about this issue. ("so ein Fass aufmachen...?").

Kick up a shindy? me? I didn't start this thread. I answered because I disagree, and AFAICS I haven't been flaming, whereas your "kick up a shindy" could be taken as inflammatory (I don't). - No matter if they're true, repeating claims long enough, people tend to take them as given, even if later proved as untrue. This is how many dubious "Best Practices" are established. To gainsay, I answered and gave my opinion. That's not a shindy ("Krach").

Besides, I have been sysadmin for nearly two decades. For that point of view, see below.

If you got an application, it needs to have a home and a UID an so on.

Not true. Does libreoffice have a home? a UID? No, neither does perl, it runs under the UID of whoever invokes it. They have a location, traditionallly applications lived under /opt or /usr/local if they weren't part of the distribution, and some still do. There are more types of applications than services e.g. mysql, web stuff and so on. Only applications that do stuff on their own behalf in an own address space distinct from the serviced user do need (or should have) a separate UID/GID.

It is simply so that Linux/Unix works like this.

Not true. This is true for users, but for system resource files Linux/UNIX discerns between bin, lib, etc, share, man and so on.

And i agree to all the points the OP mentioned.

Then think about this point from the OP alone:

  • By packaging Perl with your application stack, you control the installed modules and toolchain.

Sounds good, but it is short sighted. You end up supporting not only perl for different platforms, but as well for system libraries which are linked with perl and xs objects, if you don't distribute a statically linked perl binary. Think again. Would you ship your optimised C compiler as well? make? Again, where does your toolchain begin?

NoMachine 3 shipped a stripped-down perl 5.6.1 running (lousy) perl code compiled into binaries with something like perl2exe or such.
This is not how things should be done IMHO. See Uncool Use Of Perl: perl2exe. decompile quick steps

P.S.: You ever had a broken Perl?

Yes. On HPUX, and on an early Linux; some own buggy builds.

Bottom line: I personally believe that perl is as stable as the distribution it is part of. Building your own is in most cases just as called for as building your own C compiler to compile your custom binaries; mixing own code with the system's perl modules is as wonderful as lumping own header files with your gcc headers or /usr/include.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'