[pacman-dev] Alternatives system

[Allan McRae]

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
>> 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.

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.

Yes.

> 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
message.

> 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
messy.


Thanks for the feedback!

Allan