[matheusmoreira]

> a more comprehensive package manager like apt or dnf

I don't see how apt or dnf are any more comprehensive than pacman. What do you mean by that?

Before Arch, I used Fedora. It used yum as its package manager. That thing managed to corrupt its own databases at least twice during normal usage. Distribution major version upgrades always caused problems.

I never had problems like these after switching to Arch.

> I don’t mind compiling programs myself when needed

You only need to compile user packages. Official Arch Linux repositories host binary packages. You can download the PKGBUILD if you want.

> for most things I’m happy to not have to hand-hold my OS when it comes to updates.

99% of the time updates just work for me. Sometimes they introduce a few .pacnew files, I diff and merge them with my local files and that's it.

> Like… why?

Sometimes manual intervention is necessary. Usually it's not a big deal. The news tell you what to do and most importantly why you must do it.

The most complicated maintenance I ever experienced with Arch was when it switched /bin to /usr/bin.

[diffeomorphism]

Not PP, but to me it means much less manual intervention/more hooks etc. .

For instance, for debian I can just turn on automatic updates and basically never need manual intervention.

For arch I am not supposed to use automatic updates and have to (!) read the news.

Why? Why does arch need more manual intervention? Sure, I can do that but it just seems like a pointless waste of time.

[matheusmoreira]

> For instance, for debian I can just turn on automatic updates and basically never need manual intervention.

I question what sort of updates you're actually getting. Debian is known for being extremely outdated. This is a major reason for its stability.

Sometimes things change way too much. Sometimes they change in incompatible ways. Sometimes changes come from upstream and there's nothing the distribution can do about it. In these cases, our attention is required. Things break and we need to fix them. We need to adapt.

In order to avoid this, Debian must be outdated. It must avoid updates that break things and this necessarily means you end up using software that's years old. That's fine, it's a perfectly valid trade-off. I'm sure there are a lot of users out there whose wants and needs are perfectly filled by Debian.

If someone's interested in Arch, it's likely because of its huge repository of up-to-date unpatched software. The Arch user must be able to deal with change. Sometimes it's unavoidable and Arch culture makes it clear that users are expected to put such effort into their systems.

[diffeomorphism]

> years old.

where years<=2. Not a big deal, but yes can be annoying. That said upgrades between major versions are also usually automated and well tested (since they have lots of time to prepare and test that).

> users are expected...

The difference is what is considered "unavoidable". In particular, on other distros packagers are supposed to ... and only if that is not possible users are supposed to ...

[m01]

I don't think Debian's automatic updates do major release upgrades automatically, do they? Those IIRC do require manual intervention - if nothing else you need to run the installer & possibly respond to prompts, but possibly more depending on your system.

[pxc]

> I don't think Debian's automatic updates do major release upgrades automatically, do they? Those IIRC do require manual intervention

For major release upgrades, the official upgrade procedure is to follow instructions like these: https://www.debian.org/releases/stable/amd64/release-notes/c...

So yeah, you have a somewhat manual upgrade process once every two years, if you're not on one of the rolling release (‘testing’ or ‘unstable’).

On the other hand, you do get to choose when you make those updates. You don't get caught by surprise with them because you forgot to read the news.

Debian's documentation on Testing and Unstable[1] contains some snippets that may feel familiar to Arch users, including this very relevant bit:

> Consider (especially when using unstable) if you need to disable or remove unattended-upgrades in order to control when package updates take place.

—

https://wiki.debian.org/DebianUnstable#What_are_some_best_pr...

[pxc]

> I don't see how apt or dnf are any more comprehensive than pacman. What do you mean by that?

In terms of the core functionality of package managers, they both have more robust dependency resolvers (and dnf's is actually complete[1]).

In the case of dnf, it's also more ‘comprehensive’ in the sense that the singular CLI tool handles more package management functionality (e.g., it includes repo management), and in the sense that it supports plugins.

They're also both more comprehensive in the sense that you don't need to resort to one of a dozen third-party ‘wrappers’ in order to use the bulk of packages available in those distros' ecosystems.

—

1: See the discussion of completeness here: https://arxiv.org/pdf/2011.07851.pdf

[matheusmoreira]

> they both have more robust dependency resolvers (and dnf's is actually complete[1])

> 1: See the discussion of completeness here: https://arxiv.org/pdf/2011.07851.pdf

That's interesting. In what ways are these resolvers superior to pacman? I never had dependency resolution issues. Can you help me understand with concrete examples? Pacman is not cited anywhere on that paper.

> you don't need to resort to one of a dozen third-party ‘wrappers’ in order to use the bulk of packages available in those distros' ecosystems

Are you referring to the AUR? I believe that's more of a man power issue. Arch is a smaller project compared to the other major distributions. There aren't enough maintainers for all packages.

[pxc]

> That's interesting. In what ways are these resolvers superior to pacman?

One good example is that even though PKGBUILDs can contain version constraints (see an example here[1]), that metadata is not always present and so it is underutilized. Pacman doesn't support ‘partial upgrades’[2] (once you refresh your package lists, installing anything is ‘unsupported’ until you upgrade everything), and this is why.

(I also think that paper's notion of ‘completeness’ could probably be enriched somehow, because I've seen situations where `apt-get` will crap out but `aptitude` will offer a ‘compromise’ solution which involves downgrading some packages or removing some, and generally package managers based on libsolv do even better IME. Here Arch likely falls flatter.)

Another depsolver related issue in Pacman (related to the lack of partial upgrades) is the lack of distinction between upgrades and dist-upgrades. In apt and dnf, upgrades are non-destructive by default, meaning that they don't offer solutions that involve removing or downgrading user-selected packages. Pacman has no such distinction.

> I never had dependency resolution issues. Can you help me understand with concrete examples?

One fairly common case is that Arch just ignores the dependencies of AUR-installed packages at install time, freely upgrading packages without respect to reverse-dependencies that aren't declared in a repo.[4] Hence, ‘if packages in the official repositories are updated, you will need to rebuild any AUR packages that depend on those libraries’... every single time you upgrade, if you've installed anything from the AUR, it can leave your system with broken packages. Apt and dnf, in contrast, treat every package you install the same way. Additionally, Arch packages don't always declare version constraints for their library dependencies, and there's no CI that tests for ABI changes (there is some in Debian, although such tools can't work perfectly). So you have to use another tool (apparently one popular choice is some script from the Arch forums in 2005, lol[5]) to scan for such breakages, or else just discover them when packages don't work.

On the other hand, when Arch does consider the version constraints of installed packages, the lack of partial upgrades can be problematic for downstream distros. Any version constraints placed by downstream repos on dependencies shared with upstream can just leave you totally unable to upgrade anything at all for a while.[6]

—

1: https://github.com/archlinux/svntogit-packages/blob/master/d...

2: https://wiki.archlinux.org/title/System_maintenance#Partial_...

3: https://wiki.archlinux.org/title/Pacman/Rosetta#Basic_operat...

4: https://wiki.archlinux.org/title/Arch_User_Repository#Instal...

5: https://bbs.archlinux.org/viewtopic.php?id=13882

6: https://superuser.com/questions/1497098/pacman-unable-to-upd...

[matheusmoreira]

> Pacman doesn't support ‘partial upgrades’[2] (once you refresh your package lists, installing anything is ‘unsupported’ until you upgrade everything), and this is why.

> Another depsolver related issue in Pacman (related to the lack of partial upgrades) is the lack of distinction between upgrades and dist-upgrades.

Yes. Personally, I believe that these are features rather than issues. I don't ever want my system to be in a partially upgraded state. I treat inability to fully upgrade as a maintenance problem that I have to solve.

I'm sure there's a lot of people out there who get a lot of use out of these partial upgrades. I'm not one of them. Stuff like apt updates vs upgrades only confused me when I used those systems. I suspect other Arch users have similar opinions.

> every single time you upgrade, if you've installed anything from the AUR, it can leave your system with broken packages

> there's no CI that tests for ABI changes

Yes, those are fair points. I suppose I don't feel this pain because I don't actually use the AUR very often. When ABIs are broken, Arch maintainers will recompile and update all affected packages. Naturally, AUR packages will not be included...

[pxc]

> Yes. Personally, I believe that these are features rather than issues. I don't ever want my system to be in a partially upgraded state. I treat inability to fully upgrade as a maintenance problem that I have to solve.

You don't ever have to install without upgrading on any other package manager or distro, either, though. And the way Pacman refuses to run `pacman -Syu` if some packages can't be upgraded doesn't doesn't really save you from partial upgrades, because nothing actually stops you from running `pacman -Sy <package name>`, and that is a thing people do.

> Yes, those are fair points. I suppose I don't feel this pain because I don't actually use the AUR very often. When ABIs are broken, Arch maintainers will recompile and update all affected packages. Naturally, AUR packages will not be included...

For some years (longer than I ever continuously ran Arch) I used to run Sabayon Linux. It had its own package manager, Entropy, which was hugely impressive to me at the time. It supported all of Portage's masking facilities for managing and constraining version, but it was centered on binary packages, and it was really, really fast.

At the same time, it was sort of compatible with Portage, so you could install software with `emerge` and then reconcile the Entropy package database with the newly-installed outside packages, I think with `equo spmsync`, or something like that. Of course, working this way was totally unsupported, but it was also perfectly reliable, if you knew what you were doing. Just make sure to run `revdep-rebuild && equo spmsync` after every `equo upgrade`, or whatever.

In a way, it was very similar to Arch, except instead of the AUR, you had all of Gentoo, and, if you wanted, the overlay system (its third-party repos). The integration was a little tighter, and Portage was/is a full-fledged package manager that sees use as a core tool for other distros, not one of a dozen competing wrappers around an unofficial source control repo and Entropy, so that side of things was much more powerful as well.

It was pretty cool. But the whole bifurcation between the worlds of binary packages and the source-based package management system was a persistent annoyance. There was always some hope and desire that in the future, they could be better integrated.

Arch seems content to have this kind of eternal twilight, with a package manager that's sort of source-based and sort of binary, and to get a whole package manager out of the source-based side you need some third-party wrapper tools. Then the AUR is this de facto source-based community repo with extraordinarily low packaging standards, and it never gets binary caching. It just feels half finished, and the roadmap for Arch seems to be to leave it that way forever. (I'm sure many packages graduate into the community repos all the time, which is great.)

But there are full-fledged source-based package managers now (Nix, Guix, Homebrew) where binary caching is totally transparent. There's no two kinds of repos, one source-based and one binary, and if you modify a package that's part of the main repos, the package manager just chugs along and builds it from source like nothing happened. And when it's done, it's a first-class citizen of your system no matter where it came from.

You can basically learn not to use things from the AUR because they're second-class, especially if you maintain your own local repository or you contribute to the Arch repos. It seems lots of people do. But the way many, many people use the distro is still fundamentally split between two worlds, just like the way I used Sabayon more than 10 years ago.