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 <[email protected]> >> 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
signature.asc
Description: OpenPGP digital signature
