Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#17151 - [openal] support more backends

Attached to Project: Arch Linux
Opened by orbisvicis (orbisvicis) - Sunday, 15 November 2009, 19:47 GMT
Last edited by Allan McRae (Allan) - Friday, 27 November 2009, 10:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
. openal-soft for linux supports these backends: alsa,oss,port,pulse,wave
. all backends should be supported in the PKGBUILD as makedepends and optdepends
. openal-soft can be distributed to systems lacking these backends, and support for them will simply be disabled (openal-soft will not crash)

For example, these are the symbols provided and the libraries linked against openal-soft built with pulseaudio support:

$ ldd libopenal.so.1.10.622
linux-gate.so.1 => (0xb7808000)
librt.so.1 => /lib/librt.so.1 (0xb7784000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb776b000)
libdl.so.2 => /lib/libdl.so.2 (0xb7767000)
libm.so.6 => /lib/libm.so.6 (0xb7741000)
libc.so.6 => /lib/libc.so.6 (0xb75fa000)
/lib/ld-linux.so.2 (0xb7809000)

$ nm libopenal.so.1.10.622 | grep -i pulse
00028ed0 t alc_pulse_deinit
00028e60 t alc_pulse_init
0002a470 t alc_pulse_probe
00028ee0 t pulse_available_samples
0002ebcc r pulse_capture_device
00028f10 t pulse_capture_samples
00029170 t pulse_close
00029810 t pulse_close_capture
00029830 t pulse_close_playback
0002ebdf r pulse_device
0002ff60 d pulse_funcs
00029850 t pulse_load
00029240 t pulse_open
0002ad80 t pulse_open_capture
0002a3e0 t pulse_open_playback
0002a510 t pulse_reset_playback
00028d80 t pulse_start_capture
00028df0 t pulse_stop_capture
00028d00 t pulse_stop_playback
000297b0 t pulse_unload
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 27 November 2009, 10:38 GMT
Reason for closing:  Deferred
Additional comments about closing:  until pulseaudio, portaudio and oss are in [extra]
Comment by Corrado Primier (bardo) - Sunday, 15 November 2009, 23:24 GMT
It's not possible to add pulseaudio support, since it's in community while openal is in extra. This is an issue that has been brought up and discussed before ( FS#10930 ).
Comment by orbisvicis (orbisvicis) - Monday, 16 November 2009, 05:46 GMT
...
what ??

Are you saying that packages dependencies cannot mix repositories ?
That:
[core] cannot makedepend [community],[extra]
[extra] cannot makedepend [core],[community]
[community] cannot makepend [core],[extra]
No. Obviously, that doesn't make sense.

So are you implying a repository hierarchy ?
That:
[core] is more critical than [community],[extra]
[extra] is more critical than [community]
[community] is more critical than [core]
Certainly [core] is more critical and core than the other repositories - hence the name "core". Users wouldn't want core/kernel26 bringing in aur/glibc.
There is no such distinction between [community] and [extra]. After all, who decides that extra/wesnoth is so much more important than community/shorewall ?
Historically, [community] was designed to increase the breadth and scope of Arch packages. A visual model would place [core] as the parent with both [extra] and [community] stemming from it. As such, why not allow sharing between [extra] and [community]. Contrast this from the simplistic model you suggest: [core] -> [extra] -> [community].

Do I need to clarify that in this case the [openal] makedepends does not create a hard dependecy; rather it simply enables more features depending on how the user wishes to mix repositories.

This 'issue' may have been brough up before in (http://bugs.archlinux.org/task/10930) but it doesn't seem as though it was discussed.

If you want to continue I believe the obvious solution is to move openal-soft to [community] where it can fullfill its entire potential. But would that demote Allan McRae (sorry) to TU ?
Comment by Corrado Primier (bardo) - Monday, 16 November 2009, 10:46 GMT
By "brought up and discussed" I mean a guideline has been defined, and that, as a TU, is enough for me. It bugs me too, especially since I am the pulseaudio maintainer, but that's the way it is.

In fact, there is a repository hierarchy, and in this specific case I think it makes sense. If you have cross-repository makedepends, then you can't build a repo without using the other. It's pretty obvious that [core] should be a self-contained base system, so having makedepends outside it is plain wrong. However, we're not talking about [core]. [community] differs from [extra] in the sense that it's not maintained by the developers themselves, but by Trusted Users, who can't act on the infrastructure of the distribution, they are just packagers (and the AUR managers, but that's another point).

This doesn't mean [community] is some kind of "lesser repo", but it contains software that is somewhat less popular/standard than that which is in [extra]. Since TUs are an independent and self-ruling group (even though supported by the dev team with their resources), the Arch officially supported system shouldn't rely on them, but should be able to work (and by "work" I also mean "build") even in the case that [community] disappeared. This is my understanding of the cross-repo makedepends being forbidden.

Moving openal to [community] is not a solution, and in fact creates more problems than it solves, because you should also move packages in [extra] that depend on it. The real solution to introduce full support to pulseaudio would be moving it to [extra]. This has been in the air for a while, and I hope it happens soon, since there's quite a few packages in this situation.
Comment by orbisvicis (orbisvicis) - Monday, 16 November 2009, 18:27 GMT
You spoke logically. Granted I overreacted, but I simply am getting tired of running into the pulseaudio [community]<->[extra] wall.

Certainly pulseaudio has some bugs, and sure [application -> openal -> alsa -> pulseaudio -> alsa] output *should* work without glitch, but since it doesn't it would be nice to use openal's pulseaudio backend which does work fine [application -> openal -> pulseaudio -> alsa]... Without having to maintain my own ABS tree. Especially since this openal release fixes the pulseaudio backend.

However, not fixing this situation only adds to the perceived glitches in pulseaudio (Or unmasks the glitches, I guess it depends on one's perception). Possibly making it less likely to be incorporated into [extra] ?
Comment by orbisvicis (orbisvicis) - Monday, 16 November 2009, 18:37 GMT
Well:
oss is in [community]
portaudio is in [community]
pulseaudio is in [community]
...
What about wave support (not really crucial though) ?

Also, can we keep this bug open till these packages move to [extra] as a reminder of "stuff to do"

Loading...