[pacman-dev] Alternatives system brainstorm

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20191017/744bfa6a/attachment-0001.sig>