On 04/01/19 at 09:56am, Allan McRae wrote:
I plan to finish implementing an alternatives system for pacman post 5.2 release: https://wiki.archlinux.org/index.php/User:Allan/Alternatives
Any comments or suggestions?
"All alternatives are symlinked in /usr/bin so no need to specify the full path."
Why? Arch puts all executables in /usr/bin but other users may not.
"TODO bikeshed the separator"
We're in the rather unfortunate position that neither of our database formats can handle multiple arbitrary filenames on a single line without escaping. We can use -> in PKGBUILDs if you like, but for .PKGINFO and desc files I would pick a single character to make escaping easier.
You don't mention anywhere on the wiki what happens when a package is removed. I'm guessing alpm would remove the alternative if the link target is owned by the package and call a callback to prompt the user to select a new provider? That means the upgrade logic will need to track whether the new version still provides the alternative.
How would packages that provide a file as an alternative interact with those that provide it directly? What happens if an alternative is installed and then a user attempts to install a package that provides that file directly? Does that just fail as a file conflict? What if the package that provides the file directly is uninstalled? We'd have to scan the local database for every single file we remove (or at least those in usr/bin, if that stands) in case any packages provide that file as an alternative.
Overall, I'm torn between "this seems really neat" and "this seems like a lot of complexity for something we don't /really/ need". So, I'm going to play devil's advocate here: what's the advantage of this over the existing solutions? The example you give is bin/sh. On Arch, that could be solved by the user with NoExtract. For a more general solution, the bin/sh link could be distributed by itself in sh-bash and sh-dash packages. It's not very aesthetically pleasing, but it gets the job done with just what we already have.