Arch Linux

This request is problematic for a couple of reasons:

- A/B partition schemes are not a "normal" arrangement that a typical Arch user would target i.e. they're a bit niche. Please keep in mind Arch guiding principle No. 1 -> "Simplicity" [1]. This surely does not fit into that category.
- Downstream derivative distros are simply not supported. This is mentioned in numerous places including the C-o-C [2] and various other places in the Wiki [3][4]

> this can lead to issues

What issues? Please describe specific details of the problem instead of making sweeping generalizations.

I personally would vote against this. But it's up to the PM's (including the Glibc PM here due to it affecting dynamic linker configuration). If there is no reaction from the PM's this request will be closed as "Won't implement"

[1] https://wiki.archlinux.org/title/Arch_Linux#Simplicity
[2] https://terms.archlinux.org/docs/code-of-conduct/#arch-linux-distribution-support-only
[3] https://wiki.archlinux.org/title/Arch-based_distributions
[4] https://wiki.archlinux.org/title/Steam_Deck

You're right that this isn't a normal arrangement for a typical Arch user, but I wanted to submit this idea upstream since it'd potentially affect the packaging for several other packages, as well as there could be other cases leading to things like this upstream, such as someone wiping their installation except for /home and /etc, and trying to import their old /etc. This is a thing I've done before, and I imagine it's relatively common, or at least not super rare, so the less one has to mess around with pacman conflicts that aren't user-edited config files the better. Though it could be seen as a "failure case" in most of them, there are plenty of ways /etc and the base installation could get somewhat out of sync.

Also I did describe an issue in the original message. I'm not sure what about my explanation was vague, much less a "sweeping generalization", but in more detail: pacman fails to install fakeroot because its config file that only tells ld.so that it exists is already present on the filesystem. That file does not contain anything sensible to be edited by a user, it's only the path to fakeroot's libraries so ldconfig can properly set up its cache. It's not even a file that makes sense to be mutable, so having it in /usr is a far more common setup, where possible. Regarding modifications to packages going counter to the "simplicity" rule...well, said file is already generated by Arch downstream anyway: https://gitlab.archlinux.org/archlinux/packaging/packages/fakeroot/-/blob/main/PKGBUILD?ref_type=heads#L43

The solution in this case right now is to either delete the file first or use --overwrite, but my proposed solution would obviate that entire set of files that might prompt a user to use --overwrite, and in my opinion, the less ways that might prompt users to use --overwrite the less likely users are to use it carelessly. And the fewer hosed systems, the fewer the support requests too.