[pacman-dev] Alternatives system brainstorm

[Allan McRae]

On 28/10/19 8:30 pm, Daan van Rossum wrote:
> * 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?
> 

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