perl puts some stuff in /usr/local
 

Hi I just noticed that perl has some paths of /usr/local passed to the configure script.

I believe this is intentional. Do you know why ? I think that is if some modules are configured to live
in usr/local/lib64/perl5 then it knows about it ? Or is there some other reason ?

Generally speaking, if you compile and install stuff (without packaging it), it should go under /usr/local. Slackware is configured to enable this.

Many people prefer to package things, and so /usr/local doesn't get much love these days. I use it quite a lot for one-off binaries or scripts or other stuff I can't be bothered packaging. It's there, so I use it for it's intended purpose.

As to why PERL is configured this way:

Perl specifies three sets of installation locations.

perl, for modules included with PERL itself.
vendor, for modules installed by the provider of your PERL binary.
site, for modules installed using CPAN.

As you can see in the configure script, the site files [modules installed from CPAN] go under /usr/local/.

As rkelsen said, some folks put their third party packages in /usr/local/. I am not one of those.

If you are using cpan to install packages, then it might. I don't use cpan to install perl modules. I always build a package to do this so I can control how and were they are installed. The slackware perl package does add two empty directories in /usr/local/. One is /usr/local/share/perl5/, the other /usr/local/lib64/perl5/. On my system those directories are still empty. A full slackware installation and a number of third party perl modules all installed using a slackware package.

I do that. If you can call that (private packages) third party packages. I'd use /opt, but I have so much else going on there and it's not really suppose to be used like /usr/local. /opt is nice anyways because nobody else uses it, so I can pretty much build a whole hierarchy in there myself. So between /opt and /local, it works out pretty nice, except some stuff from some packages wants to go into /usr and not /usr/local, but those bits can go in there alone I suppose or be linked to.

With the extended use of /usr and the introduction of /home, things got a little bit out of hand it seems. But it works out pretty well, but there is alot of stuff in /usr generally. So I personally find it tidy to separate my own packages into /usr/local. I don't really know any arguments for or against either way really, but /usr/local seems like the "standard" way. If I hadn't started packaging stuff and just installed it instead I would probably use /opt personally, but that would force me to move all my /opt activity elsewhere :(

I use /usr/share/perl5/vendor_perl and/or usr/lib64/perl5/vendor_perl/ for third party perl modules. Since they are installed via a slackware package, removal if needed is simple.

The only thing I am using /opt/ for now is my VirtualBox install via the blob. I don't use /usr/local for anything.

I've not had any issues installing things with perl into /usr/local with self built packages. Only thing I noticed was perllocal.pod has to be told to append the information rather than overwrite. And ofcourse the reverse wouldn't work too well.

Seems to be that perl stuff tends to go where it is suppose to go, which is more than I can say about python and python related stuff.

You're missing out bro!

Works for me!

One other thing I do, is put a text file under /usr/local/etc called local.conf, with these contents:

Then create a symlink which points to it in /etc/fonts, eg:

Then you can just drop TTF files in /usr/local/share/fonts and they'll be accessible by all users & programs after you run "fc-cache." No need to create a package for every single random font you want to try, keeps them separated and you can easily add or delete them.

Steam and such things are actually "suppose" to go in /opt.

Libvirt is actually quite interesting in regards to /usr/local, it does everything "correct", quite fascinating. It even uses /usr/local/etc. In addition, libvirt uses things like /home/user/.cache(+/.config+/.local)/libvirt/ instead of making a huge mess in the home folders. Looks like they run a very tight operation. So if you want to have a good look at "correct" use of /usr/local and other stuff have a look at libvirt.

However, its quite annoying to me that the default location of VM images and such is somewhere in /var. But I always use /opt personally anyways.

/opt is quite great actually! you're missing out bro ;)

I guess you missed the fact that I'm using "conty.sh", so steam can go anywhere.

Incidentally, that 45 byte file isn't "steam." It's just a script which contains the following:
The reason I put conty under /usr/local is so that it's in the path... Just drop it in there and you can use it with no further action necessary. Same with the LibreOffice AppImage. Just drop it in and away you go. I've not yet finished setting up this machine and so there are a few other AppImages to go into /usr/local/bin, and some scripts which I wrote for specific tasks... again, I can just drop them in and they're immediately available to all users on the machine. They're completely out of the way and not at risk of being overwritten by system upgrades or security patches.
But this isn't a competition. I do use /opt for it's intended purpose as well. I've currently got Google Chrome, Virtualbox, Zoom and PDFSAM in there.

In the recent past, I also had Microsoft Teams and PowerShell in there. I'm not going to install them on this machine, because they were both installed for specific purposes and I don't (currently) need them.

In the distant past, KDE used to live there... and I kinda wish that it was still there by default.

EDIT: By the strictest interpretation of the FHS, it could be argued that any packages you install which are not part of the Slackware distribution should go under /usr/local. In my opinion this should include Slackbuilds... but almost nobody does it this way. We just assume that the maintainers of Slackbuilds check that default files aren't being overwritten, and that system upgrades and security patches don't overwrite the stuff we've added from there.

And in the strictest FHS non-ordinary types of executables should go into /opt.. Anyways I was just kind of making a joke ;)

But it's not really a joke, because /opt is a great location, and I see you use it to, so I guess I don't have to promote it to you. Since nobody else uses /opt generally, you could also put /opt/bin and/or /opt/sbin in the path if your opt situation allows it.

I see you do virtualisation stuff in there, I do that too, plus a bunch of other things, which is why for me /opt merit its own partition. In a way it is a home away from home with more mixed policies. But I don't like the idea of making /home into a mess and using all kinds of /home/user/folder/*/*/* etc

Never said anything about having issues. I have no issues doing what I do. I put the perl stuff where is it supposed to go. As for perllocal.pod, I delete that before creating the packages.

How so? I use LibreOffice, Steam, I have installed conty where I want it, it works.

I do do much font testing, I can always drop fonts in place, in the normal places specified in fonts.conf. I not much to create a package to install a set of fonts either.

My system, I decide what goes in to /opt.

I guess you haven't actually read the FHS. There's a link to it in my post above.
Why bother messing with that when /usr/local/* are already in the path?

If you'd like to see FHS-compliant use of /opt, check out PV's Slackbuild for Google Chrome which is in /extra on the Slackware installation iso.

The Slackbuild for Zoom which is on slackbuilds.org also does it properly.

You'll note that both of those put the whole program under /opt and then some scripts/symlinks under directories which are already in the user's path.
No, not really. Yeah, the VirtualBox program is installed under /opt, but none of the VMs are in there. They're all in the default location under my user account.

Speaking of VBox, I learned something last weekend: You can start a VM with VBox in headless mode and completely log out and the VM will stay up. I've had one running (testing a new "design" :D for backup scripts) for the past few days. It's rock solid thus far, and has impressed me to the point where I'm wondering if a Slackware/VBox stack could replace the venerable vmware ESXi in my business... Hmmm. Methinks I'll have to do more rigorous testing. Interesting times!

I have actually, but it's quite awhile ago :redface:

But I've read bits of the newer versions too. But anyways, personally I don't care THAT much about being FHS compliant, but I try to stick to the main concepts.

Have you also been testing and trying kvm/libvirt/qemu? It has come a long way, and it's incredible how much you can do actually, I've barely scratched the surface and I've gone in quite deep at times. But I know qemu a bit from before, and there were already so many things you could do with it.

If not I would highly recommend giving it a real spin, I'm fairly sure it is mature for professional use as well. Both libvirt and qemu can be directly installed on Slackware 15 without any further dependencies. But there are additional useful functions you can add ofcourse. Virt-manager is quite useful too, but it adds alot of extra work to install etc, but it's fairly managable. I've been playing around with PCI passthrough recently, and although it's not so easy or great with the "wrong" hardware (laptop), with the right hardware it should be a breeze and yield fantastic results.
And well, additionally with those you get full power lxc and containers, and the ability to "easily" cross compile with qemu, plus so many more things outside of just VM.

It's really quite amazing, each of those softwares.