FS#30125 - Support for logical OR in dependencies

Attached to Project: Pacman
Opened by Hubert Kario (tomato) - Sunday, 03 June 2012, 11:44 GMT
Last edited by Dave Reisner (falconindy) - Monday, 11 June 2012, 23:47 GMT
Task Type Feature Request
Category Scripts & Tools
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Summary and Info:
Most game packages (like recent offerings from Humble Indie Bundle: Psychonauts, Limbo, Bastion, Swords & Sworcery, Amnesia) require libraries for 3D acceleration. Adding "ati-dri" for any of those packages, makes them unusable for users of nVidia or Intel video cards. Same thing by adding "catalyst", "intel-dri", etc. The only way to sanely support all GPUs, is by adding logical or for dependencies:
"ati-dri" || "nvidia-tools" || "intel-dri" and so on.

Adding them to optdepends isn't a good solution either, there both OSS and proprietary drivers for nVidia and Ati (4 packages), lib32 and native versions (4 more packages) and Intel (2 more packages) totalling 10 packages, without actual optdependencies (like libtxc_dxtn for OSS drivers).

Steps to Reproduce:
1. On clean system with basic Xorg packages install game requiring 3D acceleration (for example: Psychonauts).
2. Run game
3. Game crashes or runs very slow because of missing DRI apis.
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 11 June 2012, 23:47 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Unmaintainable, and such situations only apply to AUR packages and binary blobs.
Comment by Allan McRae (Allan) - Sunday, 03 June 2012, 11:49 GMT
This is what provides is for.
Comment by Hubert Kario (tomato) - Wednesday, 06 June 2012, 00:03 GMT
Then why neither ati-dri nor intel-dri nor nvidia-utils have "a" provides field, let alone one shared between them?

Sorry, but IMO this is turning the problem on its head. The packager knows best what packages are needed for his package to work. Creating virtual packages won't work as this requires coordinated change in all dependent packages. Somehow I don't see it happening for "just some AUR package".

Case in point: theoretically the games I mentioned should only require libgl or lib32-libgl. But when run using OSS Radeon drivers, they actually depended on ati-dri or lib32-ati-dri!
Comment by Allan McRae (Allan) - Wednesday, 06 June 2012, 00:58 GMT
So... every time a new possibility is released that satisfies your OR list, you will add it to the list in the PKGBUILD? This seems it will always be incomplete...

And the reason those packages do not provide anything is that no-one has ever asked.
Comment by Dave Reisner (falconindy) - Wednesday, 06 June 2012, 01:55 GMT
-1 to implementing this. If there's a legit reason for adding a provide to a subset of packages, then it'll be done.
Comment by Hubert Kario (tomato) - Wednesday, 06 June 2012, 10:26 GMT
@Allan: One one hand the video drivers are quite standard so in the end we could theoretically create a set of meta-packages that make creating "requires" for games that actually work.

On the other hand we could have an application Foo that can use curl or wget to download files off the Internet, so we create a "http-ftp-downloader" meta package. But then comes a package Bar that can use curl, wget or axel. If we add provides "http-ftp-downloader" to axel it can result in breakage of package Foo. And not only that, but wget and curl are not exactly interchangeable -- they have completely different options.

Also, what meta-package you suggest that all accelerated driver packages ("ati-dri", "catalyst-utils", "nouveau-dri", "nvidia-utils", "intel-dri") should provide? I'm sure it's not libgl.
Comment by Hubert Kario (tomato) - Wednesday, 06 June 2012, 10:40 GMT
Oh, and for actual package that could benefit from this: opendbx. It has the ability to load database connection libraries on demand, so it can connect to mysql, postgres, sybase, MS SQL, Oracle, etc. If one builds it with all the engines he has to install all the client libraries, even if he needs or uses only one. The debian packages of opendbx are made this way: main library as one package, utils as second and connectors as further packages.
Comment by Kevin (anonymous_user) - Wednesday, 06 June 2012, 15:07 GMT
What about using alternative dhcp clients? Networkmanager has dhclient as an optdepend but dhcpcd as a regular depends. Neither netcfg nor Wicd's dependencies mention dhclient, though I am near certain they can work with it.

There are also cases where a package needs a font. But with the number of fonts available, using "provides" might be better.
Comment by Ionut Biru (wonder) - Wednesday, 06 June 2012, 22:56 GMT
I just closed all your bugs. please do not open individual bugs for all packages that are split from only ONE build.
Comment by Hubert Kario (tomato) - Wednesday, 06 June 2012, 23:05 GMT
Oh, nvidia-utils and nouveau-dri share code base?! That's news to me...

Seriously though, some explanation? "It's spamming" isn't a real one...
Comment by Ionut Biru (wonder) - Wednesday, 06 June 2012, 23:34 GMT
i meant to open only ONE bug report asking to implement dri or whatever you want. but imo, is not needed at all since most of our users know what video driver to install and most drivers have the right -dri as dependency, where is supported.
Comment by Hubert Kario (tomato) - Thursday, 07 June 2012, 00:52 GMT
This thread https://bbs.archlinux.org/viewtopic.php?pid=1112091 would suggest that this is a real problem. Especially on 64bit platform as some games are distributed with 32bit binaries only.

Please re-open the  FS#30171  (nvidia-utils), or should I really open a new bug with exact same description?
Comment by Ionut Biru (wonder) - Thursday, 07 June 2012, 01:19 GMT
I still don't see how "dri" provider solves the problem you are describing. they will just hit enter (because they do not read the output) and the first entry will be installed, in alphabethical order.
Comment by Hubert Kario (tomato) - Thursday, 07 June 2012, 10:49 GMT
There's quite a difference between "didn't read command output" and "doesn't posses the power of clairvoyance". We can assume that the user knows what GPU he has, but we can't assume that the user knows what additional packages are needed for his GPU to work correctly.
Comment by Hubert Kario (tomato) - Monday, 11 June 2012, 23:35 GMT
Just like I thought, adding provides to packages is more than unwelcome:  FS#30251 ,  FS#30250 . Somehow I don't think this will get any better.

Loading...