| Summary: | =media-sound/apulse-0.1.13 USE=sdk does not install binary | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dmitry Grigoriev <dimgel> |
| Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | jstein |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info | ||
Created attachment 670001 [details]
emerge --info
/usr/bin/apulse is pointless when emerged with USE=sdk, the libraries are in the normal paths and loaded by default. Packages will build with it as-if it was pulseaudio and use its libraries directly. This blocks pulseaudio installation given it'd conflict. The apulse script is used when you have the real pulseaudio installed (for packages to build with) and you want to use apulse's libraries instead. If you want the latter, build packages with USE=pulseaudio so they won't ask for apulse[sdk]. Then you can use the apulse script if you wish. I see. Thanks for answering. So this sounds like [ungoogled-]chromium ebuilds' issue. Will wait and watch how they evolve adound this. On the other hand, it should not hurt to keep those binaries, anyway. They are part of upstream, after all. Yeah unfortunately there's (currently) no centralized way to handle apulse, like a virtual or eselect pulseaudio. And with overlays (like for ungoogled-chromium) that's going to be even more up in the air and lead to conflicts. Briefly discussed in bug #744622 (I commented in #3 and #4) and ignoring #3 I personally think eselect would be the cleanest method now. Could do away with apulse[sdk] and per-ebuild workarounds, then apulse (or pipewire) could automatically work on all pulseaudio packages without wrapper scripts after running eselect (when compatible anyway). Man, it's complicated. :) More than I thought, turns out. I'd better not suggest anything. :) (In reply to Ionen Wolkens from comment #5) > .. eselect .. Can probably disregard my previous comment given pipewire's situation is changing, and may not want this only for apulse. I did see others users inquire about missing /usr/bin/apulse but it's just that they didn't realize they didn't need it and were happy without it afterward. I personally think this can just be closed, unless want to install a dummy script that does nothing for commands compatibility but that's rather questionable. It looks like to me people misunderstand what apluse[sdk] is. (In reply to Dmitry Grigoriev from comment #4) > On the other hand, it should not hurt to keep those binaries, anyway. They > are part of upstream, after all. 1) apulse is not a binary — it is just a library preload shell script 2) apulse[sdk] is *not* a part of upstream: this patch was explicitly rejected: https://github.com/i-rinat/apulse/pull/93 So let me explain: A plain stock apulse without sdk is a library which is intended to be preloaded instead of pulseaudio. This is what /usr/bin/apulse does: it just sets LD_LIBRARY_PATH so that apulse version of libpulse will be loaded. It this mode: - one still needs pulseaudio installed for headers and other build stuff required for other packages to build with pulseaudio support; - a way of running application requires to inject apulse script somewhere within the run chain, so all clients need to be modified one way or the other. I find this inconvenient, so I added SDK mode which allows to mimic pulseaudio as much as possible using apulse only. So it provides: - pulseaudio headers bundled within apulse; - pkg-config files necessary for applications to recognize pulseaudio support via apulse; - libraries installed exactly the same way as pulseaudio would install them. So apulse[sdk] is just an incomplete drop-in replacement for pulseaudio. Incomplete because it doesn't provide full pulseaudio functionality and there is no way to do this. Maybe I should add a virtual for libpulse allowing to use either pulseaudio or apulse[sdk]. But what stops me that apulse will never work with all pulseaudio applications so such virtual may confuse users even more. What are your thoughts on such virtual? |
Hi. >=net-im/telegram-desktop-2.4.5 requires apulse[sdk] which installs more headers but does NOT install /usr/bin/apulse and /usr/bin/x86_64-pc-linux-gnu-apulse; this is explicitly coded in the bottom of ebuild. But at least www-client/ungoogled-chromium-86.0.4240.183_p1::pf4public requires that binary (/usr/bin/chromium calls it to start browser). So to make ungoogled-chromium work, I temporarily installed "USE=-sdk emerge -1q --nodeps apulse", backed up two abovementioned binaries, reinstalled "emerge -1q apulse", restored binaries. Everything works. I also checked apulse project's readme on github, it's "Usage" section stil mentions apulse binary. Any reason why that binary was not installed? Weird and inconvenient, looks like breakage. Thanks.