[pacman-dev] Alternatives system
allan at archlinux.org
Mon Apr 1 04:57:31 UTC 2019
On 1/4/19 2:12 pm, Andrew Gregory wrote:
> 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
>> 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.
Make the path configurable, if anyone ever asks for that. Or if they
want a range of locations, extend it to allow optional full paths. And
this will have some configurability with the --prefix or --bindir
configuration options (at least in autotools).
> "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.
I went for two character, in a combination that is unlikely to be used
in the name of the alternative symlink itself. That way it is a split on
first occurrence. I realize that someone will try an alternative with
that pair of characters in their name... so yes, that needs addressed.
My other thought was "::" like we use to split other things in makepkg.
Would that be a compromise - two characters, but one?
> 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?
Remove the symlink to the package being removed, set it to the first
other provider found (if any). Print a notification if new symlink made.
> 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?
Yes. It will already be detected as a conflict with a file on the
system. We would just need to check to give a more informative error
> 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.
My idea was to not create the alternative symlink in this instance, and
put it down to bad packaging. Not an ideal solution, but I think there
is none in this instance.
> 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.
NoExtract could work, but having an alternative means a distribution has
decided to actually support varying the (e.g.) /bin/sh provider. That
means bashisms have been removed or appropriate shebangs added. I know
people currently do this with python->python2. The alternative system
also avoids dangling symlinks, and unowned files.
> 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.
sh-bash could not be a dependency of bash, or else this would not work.
But just installing bash does not give me the bin/sh symlink I need.
So then we make sh-bash and sh-dash provide "sh", and have everything
needing sh depend on it. So I agree, it can be done. It just becomes
Thanks for the feedback!
More information about the pacman-dev