[pacman-dev] Alternatives system brainstorm

[Daan van Rossum]

* on Thursday, 2019-10-24 10:10 +1000, Allan McRae <allan at 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?

> 
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20191028/12407c2d/attachment.sig>