Thank you for the informative post.
I felt same 3 years ago, but still rolling
Pacman is from Arch.
Don’t see it is any more difficult than other CLI package managers
Archwiki has cross-reference comparsion list - Pacman Rosetta
I can remember pkg search foo
and pkgin search foo
and apt search foo
and dnf search foo
and brew search foo
and even pacman -Ss foo
.
I can remember pkg install foo
and pkgin install foo
and apt install foo
and dnf install foo
and brew install foo
and even pacman -S foo
.
I can remember pkg delete foo
and pkgin remove foo
and apt remove foo
and dnf remove foo
and brew remove foo
and even pacman -R foo
.
I can look at the man page for pkg
and get some idea how to do something I don’t have memorized.
I can look at the man page for pkgin
and get some idea how to do something I don’t have memorized.
I can look at the man page for apt
and get some idea how to do something I don’t have memorized.
I can look at the man page for dnf
and get some idea how to do something I don’t have memorized.
I can look at the man page for brew
and get some idea how to do something I don’t have memorized.
I can look at the man page for pacman
and get some idea how to do something I don’t have memorized.
If you don’t see how it is any more difficult than other package managers, I can’t help but wonder if you don’t have much experience with other package managers. Just looking at the cross-reference you posted, pacman clearly has the more difficult usage.
Don’t kid yourself. They weren’t worrying about ease of use when they wrote pacman. It’s not the Arch way.
One thing I’ve run into fiddling with OpenSCAP/DISA STIG is that gpg-signed repos are pretty rare. Packages are signed but the repos aren’t. RHEL/CentOS/Fedora core repos are but epel isn’t. Nothing in Debian/Ubuntu world is that I know of. Not sure about Arch and the others.
Here’s the citation for the above:
From the above link:
The
gpgcheck
option controls whether RPM packages’ signatures are always checked prior to installation. To configure yum to check package signatures before installing them, ensure the following line appears in/etc/yum.conf
in the[main]
section:
gpgcheck=1
On Fedora, that option is in /etc/dnf/dnf.conf
and was already enabled. Good to know.
It’s the repo_gpgcheck
option that is problematic.
Maybe someone said that already I don´t exactly know. But for instance when I installed TS3 on my VPS I did plan to make a new user for ts3 and put ts3 into it´s home directory, then I found a guide on digital ocean while searching for a config file witch isn´t in the folder you download ts3 from.
They did useradd -d /opt/teamspeak3-server -m teamspeak3-user
essentially setting the users home directory to /opt/teamspeak3-server, witch I found a really good idea. If you install something on a desktop as your user you can just use chown -R <your_user>:<your_user> <some_folder>
(maybe the folder and the user:group are the other way around I never remember 100%, but it fails if you do it wrong anyways) to make the folder yours. Meaning permissions are never really a big deal.
So I end up just putting everything into /opt that´s not available in whatever package manager I happened to have. But that was the first time I did change the user directory of a new user specifically for that.
Apparently red hats tooling is broken and thats why they dont have repo signatures on their repos. It’s been like that for a while https://bugzilla.redhat.com/show_bug.cgi?id=1360939
Best thing you can do it put an exception in for that STIG requirement. Or possibly roll your own repos maybe…
If it isn’t in a package I generally won’t install it. That’s very, very rare. For exceptions I spin up a LXC so everything is contained. Data outside the container is in /opt.
When I looked at it a while ago the main repo had it but EPEL didn’t and they had no plans to implement it there.
It is kind of overkill. If the mirror has a certificate and the package is signed. I guess the assumption is mirrors could be compromised. Canonical doesn’t even attempt to sign repos for Ubuntu.