* on Thursday, 2019-10-24 10:10 +1000, Allan McRae <[email protected]> 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?
>
>
> 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
}
> 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? I imagine there
may be exceptional situations where the extra power will be nice to have in the
future.
Best, Daan
signature.asc
Description: PGP signature
