On 10/17/19 9:32 AM, Giancarlo Razzolini wrote:
Em outubro 17, 2019 7:53 Allan McRae escreveu:
In Debian & Fedora land, these additional files are called slaves. Note that both those distros use the "same" tool to manage these things. In addition, each alternative is given a priority. So if (e.g.) two python2 and python3 are installed at the same time, it would select the one with the higher priority. Fedora also has "ghost" files (not sure about Debian). I.e. the python3 package contains a ghost /usr/bin/python, so searching file databases gives a match.
Priorities are a nice thing to have. I think I've reported this on the bugtracker (or there was a bug report I've commented in). The example is mkinitcpio/dracut.
The only reason mkinitcpio is preferred over dracut right now is because it is on the core repo and dracut is in the extra repo. Being able to define priorities will benefit not just the alternatives system.
Then again, how will repo priority work? Will it be completely removed?
This is a completely different topic, you want "priorities" of one package over another as the default selector for interactive resolution of multiple dependency providers whereas this discussion is about whether two packages which are both installed in the same: pacman -S foo bar should prioritize one over the other when installing alternatives, and, optionally, whether installing bar *after* foo, should update the alternative that was already installed, if bar is "more priority" than foo. So the case of dracut/mkinitcpio is solved by simply declining to use --noconfirm (or alternatively, using pacstrap -i) and relegating non-preferred alternatives for core pacstrap software to [extra], which is the status quo. I don't think we've ever really made strong guarantees about how useful --noconfirm is, or blindly pressing "y" to prompts? There's a stronger argument to be made for alternatives, because ideally the "best" version of a command should always be preferred. e.g. if you install python2 as a dependency for some program, then by default /usr/bin/python -> python2 Once you install python3, one could argue it is preferred to automatically switch to the "best" version. (The counter-argument could be, maintain the status quo, first installed will win.) Now that I think about this more, we maybe don't need priorities at all, only a "default" key.
Now how does that inform our potential implementation? Mostly, I don't like that they set up all the alternatives in the post install with one long command passed to their tool. I'd prefer we had a file with a list of needed symlinks so this could happen automatically.
I agree, we shouldn't do this on post install. Ideally pacman itself should handle all the filesystem operations.
Could also include an optional priority statement? Or should that be captured in the PKGBUILD?
I think the priorities should be captured at the PKGBUILD itself. It would also make it easier for pacman to know what they are.
If priorities are implemented they should be wherever the actual alternatives are, IMO. Less fragmentation. If pacman already needs to read an "alternatives" database to know what the alternatives are to begin with, we don't need a priority without the thing it describes, encoded in the .PKGINFO on its own. ... But we should anyway focus on what the UI should be (priorities are UI) before focusing on how we implement the tracking database. :) -- Eli Schwartz Bug Wrangler and Trusted User