[pacman-dev] Alternatives system brainstorm

Giancarlo Razzolini grazzolini at archlinux.org
Thu Oct 17 19:04:19 UTC 2019

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.

Giancarlo Razzolini
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20191017/2513c718/attachment.sig>

More information about the pacman-dev mailing list