[pacman-dev] Alternatives system brainstorm

[brainpower]

Am 24.10.19 um 02:10 schrieb Allan McRae:
> On 24/10/19 12:31 am, Daan van Rossum wrote:
>> * on Wednesday, 2019-10-23 22:05 +1000, Allan McRae <allan at archlinux.org> wrote:
>>
>>> Now, ignoring my comment about not commenting... My design principle for
>>> additions to makepkg is an addition should be mostly straight forward to
>>> a packager - i.e. if you can build the software manually, you can
>>> package it.  Suggestions that look complex to package, are too complex.
>>>  Looking at your suggestion (admittedly... bourbon), it did not pass my
>>> "that seems obvious" threshold.
>>
>> I think it looks less complex in a single-line summary:
>>
>> Replace "virtual packages" (those specified with "provides=()" statements in other packages) with actual packages that can make use of links prepared by providers.
>>
>>
>> The added complexity for a packager should be small:
>> 1. packager will only work on provider packages, selector packages typically don't change
>> 2. his/her package being a provider is optional; it will still work the same way as it does now without a provider() function
>> 3. the provider() function can almost be copy-pasted (only paths need to be adjusted) from other providers or from the selector PKGBUILD
>>
> 
> 
> Compare that to the complexity of the original proposal example for python2:
> 
> 
> In the PKGBUILD:
> 
> alternatives=('python')
> 
> 
> And then provide a file python.alternative containing:
> 
> /usr/bin/python -> python2
> /usr/bin/idle -> idle2
> 
> 
> Yes - this potentially results in more complexity in the backend (I'm
> not sure it will), but is dead simple for a packager.
> 


I'll have to agree here.
My thoughts when reading that last proposal from Daan were:

Isn't that essentially an alternatives system now, just a lot more complex?

And thinking back to Daan's first proposal, wasn't the goal at that point to implement alternatives with the existing tools and functionality?
That might have had some merit. That last proposal needs a lot more than that, though.

And to me it is not very clear what happens when you've installed both providers and then want to change say from bash to dash at some point later.
Which command would I use? `pacman -S` e.g. reinstall?  That's not really clear.
Does the packager who writes the provider() function have to pay attention to that and write code that can handle all possible cases?
I didn't think too much into it, but writing a function is certainly more complex than a dumb file of key-value pairs like "/bin/foo -> foo2".
And even if it's copy-paste-able it's still code, a lot more cant go wrong than with a dump file with very simple syntax.
    (which could be a lot more easily checked for correctness by makepkg than arbitrary code)

So: A dedicated `pacman -A` seems to be a lot more clear about what I'd have to do (to me). And no code written by the packager needed.


An if you'd want hints for alternatives, maybe the alternatives name (in the original proposal the `alternatives=('python')`) could be added to the repo's DB, and then searched for?
Of course then every package having alternatives for python would have to use the same name...
But it would be a bit less data, then adding all the alternatives to the repo's db... though this could be done separately like the files.db?
Then a `pacman -Ays python` could print all providers of python, like python3, python2, python4, python-from-third-party-repo


So at this point I'd prefer the original proposal over Daan's latest, after we've bikeshedded the '->' of course. ;)


> Allan
>

-- 
regards,
brainpower

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20191024/540270d0/attachment.sig>