[pacman-dev] Alternatives system

[Andrew Gregory]

On 04/01/19 at 09:56am, Allan McRae wrote:
> Hi all,
> 
> 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.