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
