On 2015-03-14 21:48 +0100 Uwe Koloska wrote:
The app (BTW it's EdWare http://meetedison.com/robot-programming-software/) needs audio and if I understand it correctly, was developed with pyaudio (a python binding to portaudio) and then enhanced with an alternative binding to the audio part of pygame.
When I began reading this thread, I suspected that pygame may provide pyaudio, in which case your package should depend on "pyaudio" and pygame should provide "pyaudio". After the explanation above, however, it seems that there really are two completely different audio systems that your package can use. In that case. you will have to make an arbitrary choice. If upstream recommends one over the other then you should use that. If not, use the one in the official repos. Add a comment in the PKGBUILD to let the user know that one can be replaced with the other before building the package.
And since I'm not the maintainer of pyaudio nor pygame, I can't add the provides information.
Although in this case it would be incorrect for either pyaudio or pygame to provide the other (as I understand it), if a similar issue arises again you can always request that the maintainer of a package add that information.
So I really want some way to express the logic: "This app needs audio bindings but they can be provided equally well by two different packages that are besides from the audio part very different and so don't share matching provides statements."
Looks like I can't express this in a PKGBUILD.
Unfortunately this isn't possible even though there are times when it would be very useful. I believe that the matter has been discussed before and that the devs may be open to the idea but I am not sure. Regards, Xyne