Em outubro 17, 2019 12:41 Eli Schwartz escreveu:
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.
I think priorities are complimentary to alternatives. Alternatives operate at the fs level, and we're talking about operating too at the package level. We can have alternatives without priorities, sure, and I also agree that they are not the same. You can have packages that don't have any fs level conflict at all, but they could provide the same thing and therefore you could at a meta level, prioritize them.
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?
Repo precedence is ok for this, I agree.
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.
You're mixing the priority with alternatives, and as I've stated above, they are complimentary, but could certainly be achieved each 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. :)
Agreed. But I want to make the point that if we ever implement priorities, they would better serve their purpose if implemented at the packaging level. Regards, Giancarlo Razzolini
pgpbIGmgY_Nkq.pgp
Description: PGP signature
