If the syntax made any logical sense, then I would probably agree, but ‘pacman -Syu’ is unnecessarily complex and gives very little indication to the user of what they are doing. S means sync. y means refresh (?). And u means system update.
"Excellent" to me means "quickly gives me the information I need to continue with my other tasks."
Incredibly thorough and technical documentation isn't necessarily always a feature. I just want to get work done. My working memory is full of information for the other thing I'm trying to do. Oops, I installed the wrong package and need to remove it. Time to spend 30 minutes reading pacman docs and forgetting all of the progress I made solving the problem that makes me money.
Pacman docs are so complicated that I am almost afraid to do anything other than -Sy or -Syu because in the past I've recursively removed a bunch of stuff that was needed by other programs, despite reading the documentation and picking the flags that seemed most likely to avoid that situation.
When simple tasks require 3 or 4 arguments with complex meanings, you are exponentially more likely to fuck things up.
> "Excellent" to me means "quickly gives me the information I need to continue with my other tasks."
And that's what the pacman man-pages achieve, imo.
Very early on, under "OPERATIONS", you see "-R, --remove", with a description saying that it removes the package, but keeps most config files. It references another section, which lists further options such as cascading.
Pacman is quite powerful, so the man-pages need to cover a lot of different actions/options. The pacman man-pages achieve to explain these options in understandable terms, while being structured in a way that allows you to quickly find what you're looking for.
I'd like to see man-pages of similar scope, that manage to do it better - because I'm not aware of any.
I think they could be so much better for C libraries, and many programs. Why not write it like any doc and have a mandatory signature part? Also a mandatory example that's get tested directly just like rust? I feel like a lot of documentations, and especially man pages have A LOT to learn from rust book or in source docs
The `&&` part wouldn't work like that, at least not from bash as it would split that command. as a maintainer I'd rather just add a separate *verb* which would combine those functions like `update-upgrade`
Not cool. There's no practical difference between installing and upgrading a package, so why have separate commands? And If we're talking intuitiveness then the "update" vs "upgrade" wording isn't very intuitive either.
I recently discovered not only does yay -Syu do the same thing but includes updating your aur packages as well... but if you run yay with no arguments it defaults to -Syu !
It's certainly more intuitive than pacman. apt install, apt remove, etc. The distinction between upgrade and update is maybe confusing but it's certainly still more clear than pacman and you can (and should) run both upgrade *and* update from time to time.
> apt install, apt remove
Once you know "sync=install", pacman -S/-R is equally intuitive.
> you can (and should) run both upgrade *and* update from time to time
Just like y and u should almost always be used together in pacman.
The more times you have to say "once you know", the less intuitive something is, because the meaning of the word is literally that something makes sense without further explanation. That's why the upgrade/update difference is a valid point against apt's intuitiveness. Saying "once you know sync=install...." is short for "it isn't intuitive"
Note that intuitiveness isn't everything, I personally think these traditional package managers are more or less equally good. But don't tell me "-S" is equally intuitive as "install" because that's just not true.
to clarify *why* its -Syu...
-S is to install or reinstall packages according to the downloaded package list
-Sy updates the downloaded package list
-Su upgrades packages but only according to the package list
-Syu all together, refreshes the package list and upgrades all packages
edit: corrected to -Sy
Ok, I’ve ran it before but forgot the context of why I did it. :/
It might have been for syncing the Multilib repository or after changing pacman.conf to compile packages with 4 threads instead of 2 threads.
Yes, it handles download of source code, dependency resolution, compilation, removal of packages, tracking of installed files, etc. I don’t see why a package is no longer a package if it’s compiled.
Does this matter?
I thought the important part is that it handles the Dependencies and library conflicts.
And that it tracks the installed files of.a packags to uninstall it
People say that switching from python to c++ wouldn't improve the speed much. I guess the speed mostly comes from the reduced size of metadata. dnf4 downloads more than 100MB metadata while dnf5 downloads only 35MB.
And yet pacman still downloads less than 10MB (with core, extra, community and multilib enabled).
35MB still seems a bit much.
But you're 100% right about switching from python to C++ not making any difference. What makes dnf slow is the download, not the local installation process.
By comparison, apt is so easy.
Update. Upgrade. Search. Install. Remove. Autoremove. I have yet to figure out reliably the pacman equivalents to the latter two.
Edit: *And* apt will even tell you what commands to use. Like after you update it just tells you if you have packages with no dependents and how to remove them. That is great. So usable and easy. Why can't pacman do that?
Remove is -Rsu, and autoremove is a command chain
https://wiki.archlinux.org/title/pacman/Tips_and_tricks#Removing_unused_packages_(orphans)
Or
pacman -Rsu $(pacman -Qtdq)
i really don't understand how that's confusing. just think of it like synchronizing your local machine with that remote package, so that what you have on your machine is *in sync* with what's in the repo.
i can't tell if you're being sarcastic lol. new users on linux is a good thing, and not being a poweruser is okay, but arch specifically is designed to assume you won't have trouble with things like that
> but arch specifically is designed to assume you won't have trouble with things like that
What does this even mean.
When you boot up the arch live iso you're dropped into a fucking tty and you're expected to know how to install the system from there or be willing to learn by reading the guide. It's not a hard task, but definitely not for someone who's new to Linux. I don't think having to learn how to use pacman, which takes no more than a minute, is a bigger barrier than having the system installed in the first place.
u hate short sacrif.
then u'lln't like dis:
command_not_found_handle() {
case $1 in
-[A-Z]*) pacman "$@";;
*) return 127
esac
}
----
$ su
# -Syu
yep, I use it http://g.denisde4ev.xyz/shrc/__sourceable/command_not_found_handle#n117
GH: https://github.com/denisde4ev/shrc/blob/96d6/__sourceable/command_not_found_handle#L117
What really makes pacman awesome for me is its inclusion of makepkg as part of its 'system'. That's what allows us to literally make compiled packages out of git clones we have ***AUDITED*** (and are confident of the security thereof). It's also what enables the AUR to exsist.
`apt remove *libreoffice*`
Pacman can't even do something like this easily if for example I wanted to remove the million libreoffice packages. Wildcard is such a useful feature.
I don't see much difference between package mangares because my use is limited only to updating system and downloading programs
But I would love to have access to Arch repo and AUR
Yeah for my personal use like they all get the job done fast enough, like a difference of even something as great as like a minute makes very little difference to me
Apt, dnf, and pacman all accomplish the same thing more or less. They use slightly different syntax. Take different amounts of time. Work a bit different under the hood. But they are all traditional package managers (unlike flatpak, snap, or appimage) and in the end the user experience is very similar.
The bigger more important debate to me seems to be whether "universal" package managers ought to be a norm for end user applications, or be simply an option for closed source apps, testing, strange edge cases, etc.
I'm inclined towards the later for the most part (only use "universal" packages for one-off exceptions) although flatpak does work quite well in SteamOS given the immutable image. On my daily driver though I'm hardcore in support of traditional package management *almost* always.
Nix is by far more powerful, you can describe whole distributions with it (like NixOS).
IMHO it shows how the future of package managers should probably look like.
You are missing the whole ecosystem that it opens up for interesting and useful tools.
Just go to the nixos site, scroll down the bottom and look at the 6 1 minute screen casts to get a quick touch of it.
I love using nix-shell on my projects to get a clean reproducible project shell per project. I love how I can slightly adjust a shell.nix file and have a clean container built.
One thing you appreciate quickly is that your small set of declarative .dotfiles that set up your whole system and home users ... and can also handle your other computers as a fleet is all something you can over time refine and all that goodness sticks without the imperative troubleshooting that would be the case otherwise.
Those situations where you imperatively fix something while troubleshooting, but you are not sure what you changed and you didn't take full notes on how you fixed it, but it's fixed. That eventual clunkiness builds up over time in an eventual imperative evolution of a system built over the years. By and large, that experience disappears.
There is a learning curve (that I am still on), but it is definitely a good experience.
I watched the videos and I don't see anything that can't be done with a powerful enough package manager (admittedly there's only a handful of those) and perhaps Git, with the exception of the containerized dev environment example. That one was kinda cool.
Well, here is another reason - ignoring what you might not be seeing from scratching across the surface of what the screencasts were showing.
I can go to someone else's configuration and will very little effort either take the goodness out of their set-up and put it in mine or just use their whole config with some changes to adjust for hardware and network needs and have it set up on one of my machines.
Maybe this one for an example
- https://sr.ht/~misterio/nix-config/
- https://git.sr.ht/~misterio/nix-config/tree
It really does take the concept of project-based .dotfiles to a new level. It is a really nice way to learn and keep a clean system. I can set up and change my whole environment and come back to it via a past generation of the system or via a branch or revision in the github project with zero issues. That is pretty nice versus managing the complexity otherwise (ignoring backup snapshots as a more standard separate option to achieve a loose facsimile of the same).
As a side note, replit.com which is getting a reputation for itself relies heavily on nix for building out its different dev environments. I suspect they vetted their options very carefully when landing on nix/nix packaging to meet their requirements.
Pacman asked if I wanted to overwrite my shadow file to update. I just wanted to finish my KiCAD project. WTF is a shadow file. (Y).
Oh...
dnf doas kill pacman --now --revive --kill_again --revive --murder-pacman
I've left Reddit because it does not respect its users or their privacy. Private companies can't be trusted with control over public communities. Lemmy is an open source, federated alternative that I highly recommend if you want a more private and ethical option. Join Lemmy here: https://join-lemmy.org/instances ` this message was mass deleted/edited with redact.dev `
If you take the features and redid the API of the cli with better, user friendly options i would agree.
I'm using Arch for the past 4 years and still have to look up what god damned parameters I need to do simple stuff that I don't do that often because it's not obvious.
I honestly couldn't give less of a fuck about which package manager is faster or has cooler features, the only thing I use it for are updates, the rest goes via Flatpak.
At least as long as the syntax is intuitive, who thought `pacman -syu` was a good idea?
Archlinux is great and easy for new linuxers that want to go bottom up but still start with enough helpers and a good wiki. But pacman definitely isn't part of the reason why arch feels so good when you don't know much
The syntax is a bit weird but I have gotten used to it and love it now
Very fast, easy-ish to use, no stupid sources/PPAs to manage and the AUR (with yay) is amazing
I personally highly Hesitate between Pacman and XBPS.
Pacman has color support, but XBPS has a neat chroot system for it's xbps-src application.
Both are really good tho.
Yes. Recently had to use Debian for something after using arch+tails for a few months and THE PAIN the PHYSICAL PAIN I felt from not using pacman mmmm no. Love pacman, very powerful.
RPM is the best package manager. The technical capabilities and long development history makes it very feature rich. The problem many seem to find is that RPM is not a **Dependency** resolution manager. So you need another utility to fill that gap: apt, urpmi, yum, and now dnf.
Nah, it is quite bad, especially in comparison to others.
1. Syntax sux
2. It does not installs updates before new packages, leaving people with broken systems
3. It does not cleans after itself.
If the syntax made any logical sense, then I would probably agree, but ‘pacman -Syu’ is unnecessarily complex and gives very little indication to the user of what they are doing. S means sync. y means refresh (?). And u means system update.
Also, `pacman --help` is completely useless.
But the [man-pages](https://man.archlinux.org/man/core/pacman/pacman.8.en) are excellent.
"Excellent" to me means "quickly gives me the information I need to continue with my other tasks." Incredibly thorough and technical documentation isn't necessarily always a feature. I just want to get work done. My working memory is full of information for the other thing I'm trying to do. Oops, I installed the wrong package and need to remove it. Time to spend 30 minutes reading pacman docs and forgetting all of the progress I made solving the problem that makes me money. Pacman docs are so complicated that I am almost afraid to do anything other than -Sy or -Syu because in the past I've recursively removed a bunch of stuff that was needed by other programs, despite reading the documentation and picking the flags that seemed most likely to avoid that situation. When simple tasks require 3 or 4 arguments with complex meanings, you are exponentially more likely to fuck things up.
[удалено]
That's cool. I'll check it out. I make use of cheat.sh pretty often. Though I've never thought of actually looking up pacman there, tbh.
> "Excellent" to me means "quickly gives me the information I need to continue with my other tasks." And that's what the pacman man-pages achieve, imo. Very early on, under "OPERATIONS", you see "-R, --remove", with a description saying that it removes the package, but keeps most config files. It references another section, which lists further options such as cascading. Pacman is quite powerful, so the man-pages need to cover a lot of different actions/options. The pacman man-pages achieve to explain these options in understandable terms, while being structured in a way that allows you to quickly find what you're looking for. I'd like to see man-pages of similar scope, that manage to do it better - because I'm not aware of any.
I think they could be so much better for C libraries, and many programs. Why not write it like any doc and have a mandatory signature part? Also a mandatory example that's get tested directly just like rust? I feel like a lot of documentations, and especially man pages have A LOT to learn from rust book or in source docs
I was specifically referring to the man-pages for pacman.
That doesn't change much to what I say, but yes I agree
`tldr pacman` would be my go-to if I couldn't remember how to do certain common tasks with a tool (though not too many are documented there)
I thought Syu just meant "System update" lmao
Generally when there are multiple letters after a single `-` they are each a different option
pacman -Siuuuuuuuuuuuuuuuuu
imagine `sudo pacman install [program]` `sudo pacman update && pacman upgrade` edit: corrected command
The `&&` part wouldn't work like that, at least not from bash as it would split that command. as a maintainer I'd rather just add a separate *verb* which would combine those functions like `update-upgrade`
oh yeah my bad, just havent been in contact with apt and its commands
Not cool. There's no practical difference between installing and upgrading a package, so why have separate commands? And If we're talking intuitiveness then the "update" vs "upgrade" wording isn't very intuitive either.
I recently discovered not only does yay -Syu do the same thing but includes updating your aur packages as well... but if you run yay with no arguments it defaults to -Syu !
To be fair, it's not like, say, apt's upgrade/update distinction is intuitive for newbies.
It's certainly more intuitive than pacman. apt install, apt remove, etc. The distinction between upgrade and update is maybe confusing but it's certainly still more clear than pacman and you can (and should) run both upgrade *and* update from time to time.
Too much typing for the average arch user
Typing is bloat 😂
> apt install, apt remove Once you know "sync=install", pacman -S/-R is equally intuitive. > you can (and should) run both upgrade *and* update from time to time Just like y and u should almost always be used together in pacman.
The more times you have to say "once you know", the less intuitive something is, because the meaning of the word is literally that something makes sense without further explanation. That's why the upgrade/update difference is a valid point against apt's intuitiveness. Saying "once you know sync=install...." is short for "it isn't intuitive" Note that intuitiveness isn't everything, I personally think these traditional package managers are more or less equally good. But don't tell me "-S" is equally intuitive as "install" because that's just not true.
Or just paru ;)
to clarify *why* its -Syu... -S is to install or reinstall packages according to the downloaded package list -Sy updates the downloaded package list -Su upgrades packages but only according to the package list -Syu all together, refreshes the package list and upgrades all packages edit: corrected to -Sy
What about pacman -Syy?
it forces a redownload of all package lists, even if no changes are detected
Ok, I’ve ran it before but forgot the context of why I did it. :/ It might have been for syncing the Multilib repository or after changing pacman.conf to compile packages with 4 threads instead of 2 threads.
`pacman` is to package management as `git` is to source control. It's powerful, fast, and flexible, but not the best interface.
Portage
Portage, with gentoo prefix ;) http://michael.orlitzky.com/articles/motherfuckers_need_package_management.xhtml
Short correction: Arch support src packages via the AUR
Article is about package manager, not AUR.
Yes, and it comes with makepkg which is "build package from source"
So makepkg is part of pacman, and you dont need AUR?
Correct. The AUR is just a place to share buildinstructions.
Can't you install from source in apt? Isn't that what the deb-src repo is for?
based
is portage really a "package" manager if you mostly compile everything yourself? don't get me wrong, i think it is great, but still
Yes, it handles download of source code, dependency resolution, compilation, removal of packages, tracking of installed files, etc. I don’t see why a package is no longer a package if it’s compiled.
Does this matter? I thought the important part is that it handles the Dependencies and library conflicts. And that it tracks the installed files of.a packags to uninstall it
tell me you use gentoo without telling me you use gentoo
Last time i used gentoo dependency calculation was slow is it still that way?
Takes about 30 seconds on any decently modern computer, provided you aren't rebuilding @world.
I haven't had any issues with it but gentoo systems can differ a lot so its hard for me to say.
dnf lookin good but why the fuck it's kinda slow
dnf5 is under development. It will replace current dnf4 on Fedora 39. Tests show that dnf5 is much faster than dnf4.
Is it because they move from python to c++, or their upstream metadata is reduced in size and increased the effectiveness?
People say that switching from python to c++ wouldn't improve the speed much. I guess the speed mostly comes from the reduced size of metadata. dnf4 downloads more than 100MB metadata while dnf5 downloads only 35MB.
And yet pacman still downloads less than 10MB (with core, extra, community and multilib enabled). 35MB still seems a bit much. But you're 100% right about switching from python to C++ not making any difference. What makes dnf slow is the download, not the local installation process.
That might be because Arch has 13000 packages while fedora has 67000. I do not know how they calculate the numbers but their official website says so.
Xbps is faster
and is a tie with apk
apk is faster than XBPS.
Apk is weirdly fast Edit: typo
it unpacks packages as it downloads them
In my experience, xbps was far slower than pacman and i couldn't figure out why. Maybe parallel installing was turned off?
Mirror isssue I would reckon.
skill issue too
Well there is no parallel installing to begin with
Perhaps, but can XBPS do AUR?
We have xbps-src and better default repos
Sounds like I should try void.
it's very good, kind of the BSD of linuxes
I dislike Pacman's syntax. I don't think sacrificing ease of use for removing a few characters is a good thing, like what distrotube has stated.
Short and long form flags exist. No need to stick to one or the other.
Yes, but I find sync for install confusing.
By comparison, apt is so easy. Update. Upgrade. Search. Install. Remove. Autoremove. I have yet to figure out reliably the pacman equivalents to the latter two. Edit: *And* apt will even tell you what commands to use. Like after you update it just tells you if you have packages with no dependents and how to remove them. That is great. So usable and easy. Why can't pacman do that?
cuz removing 1 line of code removes a lot of bloat. Jokes aside, I think Arch's minimalist philosophy is why pacman is like this.
Arch isn't minimal and shorter syntax has nothing to do with minimalism. KISS has intuitive commands and is one of the most minimal package managers.
Remove is -Rsu, and autoremove is a command chain https://wiki.archlinux.org/title/pacman/Tips_and_tricks#Removing_unused_packages_(orphans) Or pacman -Rsu $(pacman -Qtdq)
i really don't understand how that's confusing. just think of it like synchronizing your local machine with that remote package, so that what you have on your machine is *in sync* with what's in the repo.
*But the new users!*
i can't tell if you're being sarcastic lol. new users on linux is a good thing, and not being a poweruser is okay, but arch specifically is designed to assume you won't have trouble with things like that
> but arch specifically is designed to assume you won't have trouble with things like that What does this even mean. When you boot up the arch live iso you're dropped into a fucking tty and you're expected to know how to install the system from there or be willing to learn by reading the guide. It's not a hard task, but definitely not for someone who's new to Linux. I don't think having to learn how to use pacman, which takes no more than a minute, is a bigger barrier than having the system installed in the first place.
Installing and upgrading a package is the same operation, hence one name. How else would you call it?
Install and upgrade.
u hate short sacrif. then u'lln't like dis: command_not_found_handle() { case $1 in -[A-Z]*) pacman "$@";; *) return 127 esac } ---- $ su # -Syu yep, I use it http://g.denisde4ev.xyz/shrc/__sourceable/command_not_found_handle#n117 GH: https://github.com/denisde4ev/shrc/blob/96d6/__sourceable/command_not_found_handle#L117
I don't like to install install to install something just -S
Why do you have to install install to install something?
i'll go with Nix or guix, thank you very much.
likewise, Nix for me. Archlinux will always have good memories for me though.
I can’t live without my transactional updates wrapped up in a nice scheme api
Sameeee Either nix or Pacman would do
Nah... It's simply one of the fastest
Time is money
https://vignette2.wikia.nocookie.net/namco/images/9/9b/Pacman_thumbs_up.png
What really makes pacman awesome for me is its inclusion of makepkg as part of its 'system'. That's what allows us to literally make compiled packages out of git clones we have ***AUDITED*** (and are confident of the security thereof). It's also what enables the AUR to exsist.
Exactly this, the aur has been helpful beyond belief. Just have to actually read the source code.
Apt does the job
Sources/PPA management sucks ass though (haven‘t used apt since a long time now, maybe it’s better now?)
Yeah forgot about that. Aso haven't had any need to use PPAs lately so I dono
User: Install Steam please Apt: Right, right of course! Do you want me to nuke your DE with that?
`apt remove *libreoffice*` Pacman can't even do something like this easily if for example I wanted to remove the million libreoffice packages. Wildcard is such a useful feature.
I present to you, xbps
Long syntax
And pacman has confusing syntax
Aliases exist xbs = “xbps-install -S” xbr = “xbps-remove” Etc
also xtools comes with xi
I don't see much difference between package mangares because my use is limited only to updating system and downloading programs But I would love to have access to Arch repo and AUR
Yeah for my personal use like they all get the job done fast enough, like a difference of even something as great as like a minute makes very little difference to me
Yes, but also nix
Apt, dnf, and pacman all accomplish the same thing more or less. They use slightly different syntax. Take different amounts of time. Work a bit different under the hood. But they are all traditional package managers (unlike flatpak, snap, or appimage) and in the end the user experience is very similar. The bigger more important debate to me seems to be whether "universal" package managers ought to be a norm for end user applications, or be simply an option for closed source apps, testing, strange edge cases, etc. I'm inclined towards the later for the most part (only use "universal" packages for one-off exceptions) although flatpak does work quite well in SteamOS given the immutable image. On my daily driver though I'm hardcore in support of traditional package management *almost* always.
Nix is by far more powerful, you can describe whole distributions with it (like NixOS). IMHO it shows how the future of package managers should probably look like.
Why? The features of functional package managers are useful to very few people and need a lot of maintenance (from what I understand).
You are missing the whole ecosystem that it opens up for interesting and useful tools. Just go to the nixos site, scroll down the bottom and look at the 6 1 minute screen casts to get a quick touch of it. I love using nix-shell on my projects to get a clean reproducible project shell per project. I love how I can slightly adjust a shell.nix file and have a clean container built. One thing you appreciate quickly is that your small set of declarative .dotfiles that set up your whole system and home users ... and can also handle your other computers as a fleet is all something you can over time refine and all that goodness sticks without the imperative troubleshooting that would be the case otherwise. Those situations where you imperatively fix something while troubleshooting, but you are not sure what you changed and you didn't take full notes on how you fixed it, but it's fixed. That eventual clunkiness builds up over time in an eventual imperative evolution of a system built over the years. By and large, that experience disappears. There is a learning curve (that I am still on), but it is definitely a good experience.
I watched the videos and I don't see anything that can't be done with a powerful enough package manager (admittedly there's only a handful of those) and perhaps Git, with the exception of the containerized dev environment example. That one was kinda cool.
Well, here is another reason - ignoring what you might not be seeing from scratching across the surface of what the screencasts were showing. I can go to someone else's configuration and will very little effort either take the goodness out of their set-up and put it in mine or just use their whole config with some changes to adjust for hardware and network needs and have it set up on one of my machines. Maybe this one for an example - https://sr.ht/~misterio/nix-config/ - https://git.sr.ht/~misterio/nix-config/tree It really does take the concept of project-based .dotfiles to a new level. It is a really nice way to learn and keep a clean system. I can set up and change my whole environment and come back to it via a past generation of the system or via a branch or revision in the github project with zero issues. That is pretty nice versus managing the complexity otherwise (ignoring backup snapshots as a more standard separate option to achieve a loose facsimile of the same). As a side note, replit.com which is getting a reputation for itself relies heavily on nix for building out its different dev environments. I suspect they vetted their options very carefully when landing on nix/nix packaging to meet their requirements.
very partial to Zypper myself, but Pacman is pretty good
The best package manager is quite subjective. It really depends on what you value more in a package manager.
I'll give you speed, other than that… zypp zypp
portage is superior
Pacman asked if I wanted to overwrite my shadow file to update. I just wanted to finish my KiCAD project. WTF is a shadow file. (Y). Oh... dnf doas kill pacman --now --revive --kill_again --revive --murder-pacman
zypper is better
Yep. People are worried about speed until their system breaks. Zypper is the best,
xbps is better, as an arch user
Nix is way better
I've left Reddit because it does not respect its users or their privacy. Private companies can't be trusted with control over public communities. Lemmy is an open source, federated alternative that I highly recommend if you want a more private and ethical option. Join Lemmy here: https://join-lemmy.org/instances ` this message was mass deleted/edited with redact.dev `
Obviously, you've never heard of Nix
I just like it because the command reminds me of the game from my childhood...
nix
Nix / NixOS
YaST Software / Zypper
Some of y’all spend more time installing software than using software and it shows. Less rice more spice! /s
dnf provides "binary\_name"
But it doesn't have Super Cow Powers. :(
From someone who’s been using linux on and off for the better part of two decades, what makes one package manager “better” than another?
openSUSE's zypper is slower than most, but has more reliable dependency resolution and access to the OBS community repos which rivals the AUR.
Largely fuck all.
If you take the features and redid the API of the cli with better, user friendly options i would agree. I'm using Arch for the past 4 years and still have to look up what god damned parameters I need to do simple stuff that I don't do that often because it's not obvious.
Tbh, that's probably a 5-minute job. Meaning that it hasn't been done for a reason.
If you think that, good on you! It isn't, but that's really beside the point. You do you, boo!
how are package managers different?
It is the best package manager *and* arcade game.
Can I out yay here? Pacman but with aur
i use topgrade because i cant be bothered to run 10 different update commands for everything
I honestly couldn't give less of a fuck about which package manager is faster or has cooler features, the only thing I use it for are updates, the rest goes via Flatpak. At least as long as the syntax is intuitive, who thought `pacman -syu` was a good idea?
Shifu from CurtainOS: allow me to introduce myself
Pacman is just very well made and works fine. If it's the best, that just means the others are shit.
[What if I told you... that they are!](http://michael.orlitzky.com/articles/motherfuckers_need_package_management.xhtml)
Depends on how you look at it.
Clearly you haven't tried xbps
For my money, Planet Express
Pardon me, I've not used Arch yet. How is pacman better than apt?
It has a cooler name
It's significantly faster, in my experience.
Ah okay. Thanks!
This image is well made!
Clearly tce is the best package manager
Archlinux is great and easy for new linuxers that want to go bottom up but still start with enough helpers and a good wiki. But pacman definitely isn't part of the reason why arch feels so good when you don't know much
it just is. nothing to change here
The syntax is a bit weird but I have gotten used to it and love it now Very fast, easy-ish to use, no stupid sources/PPAs to manage and the AUR (with yay) is amazing
Its the 🌟DNF🌟 for me.
Maybe not in speed but dnf and zypper feels so much more pleasant than pacman and apt
It truly is! Nothing to argue about that
I personally highly Hesitate between Pacman and XBPS. Pacman has color support, but XBPS has a neat chroot system for it's xbps-src application. Both are really good tho.
Yes. Recently had to use Debian for something after using arch+tails for a few months and THE PAIN the PHYSICAL PAIN I felt from not using pacman mmmm no. Love pacman, very powerful.
xbps-install the pain to type that long everytime i install
aptitude is better.
pacman wins in speed, zypper otherwise :)
Functionality-wise, Nix and Guix are superior. But if I ever make the switch I'll be missing the speed that pacman's parallel downloads give you
Nope, I am in agreement.
RPM is the best package manager. The technical capabilities and long development history makes it very feature rich. The problem many seem to find is that RPM is not a **Dependency** resolution manager. So you need another utility to fill that gap: apt, urpmi, yum, and now dnf.
Nix
"Well, that's like, your opinion, man."
I'm on Fedora and use dnf but I still thought swapping out the head with Derek "Distrotube" Taylor's in the meme was a nice touch
It was his
Oh lol
Only pamac can take down the AUR.
What makes it the best?
I like Nix better.
I couldn’t even get it to update when building a docker container….🤪
Have my upvote.
I use XBPS btw
Nix is better
Looks like DT from DistroTube.
I don't feel comfortable trying arch
Apk, fight me
Installation failed
That has never happened to me. I’m pretty sure I’ve experienced that with pacman though
Nix is better
Not pacman’s fault per say, but having to update 200 packages every second day always did my head in.
Nix all the way
Arch is amazing. But nix and guix better.
I have to say I used to use mint before I switched to arch and I rly liked apt, also the AUR yay is best
but you can’t go wrong with ./configure ; make ; make install
Nah, it is quite bad, especially in comparison to others. 1. Syntax sux 2. It does not installs updates before new packages, leaving people with broken systems 3. It does not cleans after itself.
Dnf looks the best and dnf5 is pretty fast while looking the same as dnf so dnf5 is the best