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