SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
As rkelsen said, some folks put their third party packages in /usr/local/. I am not one of those.
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.
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.
me@slacktop:~$ ls -la /usr/local/bin
total 1614308
drwxr-xr-x 2 root root 4096 May 29 16:20 ./
drwxr-xr-x 13 root root 4096 Feb 15 16:07 ../
-rwxr-xr-x 1 root root 438633664 May 29 15:51 LibreOffice-still.full-x86_64.AppImage*
-rwxr-xr-x 1 root root 1214393539 May 29 15:31 conty_lite.sh*
lrwxrwxrwx 1 root root 38 May 29 16:17 libreoffice7.2 -> LibreOffice-still.full-x86_64.AppImage*
lrwxrwxrwx 1 root root 13 May 29 15:39 lutris -> conty_lite.sh*
lrwxrwxrwx 1 root root 13 May 29 15:39 pcmanfm -> conty_lite.sh*
lrwxrwxrwx 1 root root 13 May 29 15:39 playonlinux -> conty_lite.sh*
-rwxr-xr-x 1 root root 45 May 29 15:40 steam*
lrwxrwxrwx 1 root root 13 May 29 15:37 wine -> conty_lite.sh*
me@slacktop:~$
Works for me!
One other thing I do, is put a text file under /usr/local/etc called local.conf, with these contents:
Code:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- /etc/fonts/local.conf file to configure system font access -->
<fontconfig>
<!-- Font directory list -->
<dir>/usr/local/share/fonts</dir>
</fontconfig>
Then create a symlink which points to it in /etc/fonts, eg:
Code:
me@slacktop:~$ ls -la /etc/fonts/local.conf
lrwxrwxrwx 1 root root 31 May 29 16:24 /etc/fonts/local.conf -> /usr/local/etc/local.conf
me@slacktop:~$
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.
me@slacktop:~$ ls -la /usr/local/bin
-rwxr-xr-x 1 root root 45 May 29 15:40 steam*
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
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.
Quote:
Originally Posted by zeebra
/opt is quite great actually! you're missing out bro
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.
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.
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
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.
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.
Quote:
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.
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.
And in the strictest FHS non-ordinary types of executables should go into /opt.
I guess you haven't actually read the FHS. There's a link to it in my post above.
Quote:
Originally Posted by zeebra
you could also put /opt/bin and/or /opt/sbin in the path if your opt situation allows it.
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.
Quote:
Originally Posted by zeebra
I see you do virtualisation stuff in there
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" 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 guess you haven't actually read the FHS.
If you'd like to see FHS-compliant use of /opt
I have actually, but it's quite awhile ago
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.
Quote:
Originally Posted by rkelsen
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" 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!
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
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!
