Hi, Maybe a dumb question, maybe I simply missed something. While updating my gentoo system, I'm currently in the middle of a process which consist to try to resolve multiple dependencies puzzles. media-sound/pulseaudio is installed with realtime useflag disabled, which is the default. sys-auth/rtkit is pulled in by wine-staging ebuild. In wine-staging ebuilds we can find this : > pulseaudio? ( > realtime? ( sys-auth/rtkit ) > ) Why does it depend directly on sys-auth/rtkit ? Shouldn't it depends on pulseaudio with realtime support ? Something like this : > pulseaudio? ( media-sound/pulseaudio[${MULTILIB_USEDEP},realtime=] ) Also, why does realtime useflag enabled by default ? Since realtime useflag is disabled by default in pulseaudio ebuild, I don't see why wine-staging enabled it by default, and directly pulls in sys-auth/rtkit. Thanks. Reproducible: Always
Ancient bug #487152 comment #3 has some history on this, however those patches are gone and wine does not use rtkit directly at all.
It may(?) have some worth in that it allows pulseaudio to use rtkit even with its non-default realtime (pulseaudio's realtime flag does nothing but pull the dep). So if removed it could surprise some users after a depclean... But still I'd say that's not the wine ebuild's business to deal with this if wine doesn't actually need it, both the flag and dependency should be removed, and shouldn't request pulseaudio[realtime] either. Given the above comment it's probably just a forgotten dep anyhow, but sarnex may know better.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a93609bbc6d8013ae7f10568a45db6589acc6005 commit a93609bbc6d8013ae7f10568a45db6589acc6005 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-09 17:37:48 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-10 09:47:15 +0000 app-emulation/wine-staging: add 7.17 using new ebuild See wine-vanilla-7.0-r3 commit for main list of changes, mostly same beside handling the patchset. For some notable staging-specific differences with original ebuilds: - no IUSE=staging, not planning to do merged ebuild logic currently - no IUSE=pipelight, not seeing a need to have a USE to disable this tiny patchset (seems was formerly treated specially given it was provided as unofficial patches in app-emulation/wine:0) - add IUSE=xattr fwiw, @system packages keep it optional too and disabling can have bit extra meaning for less multilib deps - use an array to pass patchinstall.sh options - add MY_WINE_STAGING_CONF for users to set their own exclusions - for live, now fetching the wine commit that current staging been based on by default (otherwise too volatile, users can still still use EGIT_OVERRIDE_* if wanted) Closes: https://bugs.gentoo.org/744829 Closes: https://bugs.gentoo.org/746338 Closes: https://bugs.gentoo.org/753698 Closes: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/wine-staging/Manifest | 2 + .../files/wine-staging-7.17-llvm-libunwind.patch | 9 + .../files/wine-staging-7.17-noexecstack.patch | 7 + .../wine-staging/wine-staging-7.17.ebuild | 350 +++++++++++++++++++++ 4 files changed, 368 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dda498c8aa4face18f47e637d1888f681f44ae6a commit dda498c8aa4face18f47e637d1888f681f44ae6a Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-10 04:17:12 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-10 09:47:14 +0000 app-emulation/wine-vanilla: add 7.17 using new ebuild See wine-vanilla-7.0-r3's commit for details Bug: https://bugs.gentoo.org/744829 Bug: https://bugs.gentoo.org/746338 Bug: https://bugs.gentoo.org/753698 Bug: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> app-emulation/wine-vanilla/Manifest | 1 + .../wine-vanilla/wine-vanilla-7.17.ebuild | 316 +++++++++++++++++++++ 2 files changed, 317 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f53d1bd478c460721be936f7691ba5744471edb6 commit f53d1bd478c460721be936f7691ba5744471edb6 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2022-09-09 14:37:37 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2022-09-10 09:47:14 +0000 app-emulation/wine-vanilla: use new ebuild for 7.0-r3 Based on wine-proton's rewritten ebuild with added logic to handle additional USE that are being forced in wine-proton but should be optional here. 7.17 to follow in a bump. Main goal is to make this hopefully easier to maintain and cleanup ancient constructs that haven't been relevant in 10+ years. Also fixes a few misc issues. List likely incomplete as haven't kept track of everything while writing wine-proton's ebuild, but for some notable differences compared to older ebuilds: - use upstream's way to handle multilib (--with-wine64) to ensure wow64 combined build is done as it should > like before it still allows 4 types, outline for clarity: amd64, abi_x86_32, abi_x86_64: full wow64, uses --with-wine64 amd64, -abi_x86_32, abi_x86_64: wine -> wine64, no --with-wine64 amd64, abi_x86_32, -abi_x86_64: default 32bit-only build, on 64bit x86, abi_x86_32, -abi_x86_64: default with nothing special - some other differences for ABI handling: > use /usr/lib/<variant> for both rather than lib64 > read CROSSCC_x86/CROSSCC_amd64 on top of wine's CROSSCC > CROSS flags check is done per-ABI rather than once for both > rely on MULTILIB_COMPAT to set REQUIRED_USE - force ld.bfd wrt bug #867097 and bug #744829, the various linker tricks currently make it unrealistic to use anything else and workarounds are insufficient for non-broken runtime even if it builds (note can still build with clang, it's lld/mold that lead to issues) - set QA_TEXTREL wrt bug #746338, seems expected given wine does these with -fno-PIC -Wl,-z,notext (aka don't treat DT_TEXTREL as errors) - fix execstack warnings for stub libraries (likely benign, just noisy) - handle stripping of PE files manually given portage doesn't know the right strip executable to use which resulted in warnings, potential mangling, and ignoring .exe/.dll files - use --<exact> for eselect-wine rather than --all to reduce noise - nonfatal eselect-wine for prerm, this allows removing wine in the event it was already deregistered notably if postinst's eselect-wine failed (which gives an error but doesn't fail installation) - do maintainer-oriented sanity check for matching mono on top of gecko's, check is always done regardless of USE and is only nonfatal for live version - various deps revisions, hopefully more pedantic, for some notes: > split dlopen'ed deps for clarity, these "could" be runtime optfeatures but realistically want wine to work as expected (split makes it easier to handle app-portage/iwdevtools' qa-vdb reports which gives a list of libraries it believes can be removed... and it turns out to be the dlopen list) > yacc -> bison, this explicitly looks for bison > XML-Simple -> XML-LibXML, it's what winemaker actually uses > move extras under X?, per configure.ac they are no-op if X is unset - IUSE newly enabled by default: > gstreamer: crippled without this and is only set by gnome profile > mingw: wine been focusing on PE conversions and most distros offer mingw builds making users hit unexpected issues if disabled (no longer need crossdev for this, so default is more reasonable now) > sdl: input devices like gamepads not being functional can be unexpected and unclear as to why (albeit desktop profile sets this) > vkd3d: matches later versions that have it always enabled as a bundled PE build > vulkan: grown in importance and matches already-default opengl - IUSE newly disabled by default: > perl: winemaker/dump are very rarely needed and may pull a chain of modules for no reason > udisks: unimportant for common usage and handled by desktop profile - IUSE added (disabled by default): > debug: to skip stripping of PE files, like other mingw packages > llvm-libunwind: use over libunwind - IUSE removed: > mp3: was a no-op forgotten IUSE > oss: this is ossv4 support which needs unpackaged media-sound/oss and a patched kernel, makes little sense to expose as USE that sometime confuse users (use EXTRA_ECONF=--with-oss instead) > realtime: wrt bug #753698, drop dependency on rtkit > run-exes: leave .desktop's MimeType alone (force current default), not convinced a USE to sed MimeType out makes sense and untrusted potentially harmful files are not limited to .exe, could be doing this for every .desktop (...don't open untrusted files, or use a user patch if really must) > threads: leave it up to defaults, no need to touch this (dos/samba optfeature'ish USE could make sense to remove but left alone for now) - no warnings if disable mono/gecko defaults, does not feel necessary - skip some unnecessary cruft, like > PATCHES_BIN code, unsure when this was last used > QA_DESKTOP_FILE, these are installed by wine-desktop-common > PLOCALES, wine been generating po/LINGUAS itself since wine-1.9.5 > xdg.eclass, updates are done by eselect-wine after putting files in a path xdg tools will recognize (meaningless in ebuild) > --enable-hal, like tons of --enable-* switches, it wasn't needed and only an issue because ebuild used to pass a hard --disable-hal > opencl 32bit check, virtual/opencl is different nowadays using a glvnd-like loader and it doesn't prevent building support even if there's ultimately no backend to load (not our job to check that), furthermore the test used eselect-opencl that is gone from the tree > env_vcs_vars: the eclass already inform of variables to use even in a multi-repo context (and -vanilla is not even multi) - not skipping l18n man pages + README based on LINGUAS (normally not used for this and is small files, use INSTALL_MASK if unwanted) - no multislot-apploader.patch, haven't found a way in which this matters with current layout and scripts seem to use the right slot - no multilib-portage.patch, need to support multilib-portage was already non-existent and got further dropped by a council vote - no winegcc.patch, unsure if was still relevant with current ebuilds but there is no known winegcc build issues with the new one - always run make_requests to handle patches rather than check md5sum, make_vulkan could make sense too but that requires adding python logic to the ebuild for something that's normally unneeded (make_requests is only optional for vanilla without user patches) - not using gentoo-wine-patches tarball, debatable but feel there's too few patches (and small) to be worth sharing across variants anymore (which may need rebasing anyway), and this skips the need to have per-developer URI logic/updates to maintain the tarball > also drop the hires icon it contained, questionable whether Gentoo should even handle this rather than use upstream's (ideally ping upstream's issue for attention instead, but could consider reinstating if it's really wanted) - use Wine's new gitlab, has more capabilities (e.g. shallow clones) - LICENSE update to include bundled libraries, e.g. libpng (not unbundled given PE files can't use system's ELF libraries) - copyright header reset to 2022-only, not based on old ebuilds Attempted to support tests (which previous ebuilds restricted), but concluded that skipping enough for a working subset would be too difficult to maintain, not to mention sandbox violations to fix and how easily it can hang. Bug: https://bugs.gentoo.org/744829 Bug: https://bugs.gentoo.org/746338 Bug: https://bugs.gentoo.org/753698 Bug: https://bugs.gentoo.org/867097 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../files/wine-vanilla-7.0-llvm-libunwind.patch | 9 + .../files/wine-vanilla-7.0-noexecstack.patch | 7 + .../wine-vanilla/wine-vanilla-7.0-r3.ebuild | 318 +++++++++++++++++++++ 3 files changed, 334 insertions(+)
