On 28/10/19 8:30 pm, Daan van Rossum wrote:
* on Thursday, 2019-10-24 10:10 +1000, Allan McRae <allan@archlinux.org> wrote:
Compare that to the complexity of the original proposal example for python2:
In this design, will /usr/bin/python be owned by a package like in the selector-provider design?
Yes. For -Qo, it would be owned by the package currently providing the alternative (with a note showing it is not a real ownership). For -Fo, it would be own by all packages that provide that file.
In the PKGBUILD:
alternatives=('python')
selector=('python') provides=('python-provider') #-- unnecessary if backend infers this
And then provide a file python.alternative containing:
/usr/bin/python -> python2 /usr/bin/idle -> idle2
provide() { mkdir -p usr/bin ln -s /usr/bin/python2 usr/bin/python ln -s /usr/bin/idle2 usr/bin/idle }
That limits you to only having one alternative option per package.
Yes - this potentially results in more complexity in the backend (I'm not sure it will), but is dead simple for a packager.
Complexity for developers vs complexity for users is a delicate tradeoff.
The python.alternative design involves slightly less text to write for a maintainer, OK, but splits it over two files instead of one.
A function is more powerful than a list of key-value pairs. Can you handle alternative lua include files with a list of key-value pairs?
Yes - all alternatives are symlinks. Symlinks are key-value pairs. Include directories can be symlinked too.
I imagine there may be exceptional situations where the extra power will be nice to have in the future.
Do you have a plausible example where a list of symlinks is not enough? Allan