my world updates got blocked due to some conflict caused by pipewire I don't want another bloatware on my system, but there's no flag to disable it looks like FreeBSD was able to cope with that already - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270982 ... can Gentoo too, please?
No plans until such an option exists upstream.
*** Bug 913421 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=5b2d7fe7cbffd1ac4e1fbb1ab0a6731eb66bfb0e commit 5b2d7fe7cbffd1ac4e1fbb1ab0a6731eb66bfb0e Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2023-09-01 18:58:33 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-09-01 18:58:33 +0000 kde-apps/kdenetwork-meta: Add IUSE +screencast for kde-apps/krfb Bug: https://bugs.gentoo.org/910168 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-apps/kdenetwork-meta/kdenetwork-meta-23.08.49.9999.ebuild | 4 ++-- kde-apps/kdenetwork-meta/kdenetwork-meta-9999.ebuild | 4 ++-- kde-apps/kdenetwork-meta/metadata.xml | 1 + 3 files changed, 5 insertions(+), 4 deletions(-) https://gitweb.gentoo.org/proj/kde.git/commit/?id=0384a1d149e88dfab5c6a0fd0d0336c5e66dffac commit 0384a1d149e88dfab5c6a0fd0d0336c5e66dffac Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2023-09-01 18:51:37 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-09-01 18:56:57 +0000 kde-apps/kdegraphics-meta: Add IUSE +screencast for kde-apps/spectacle This makes it at least possible to build the meta without pulling in kde-plasma/kpipewire, even if that means losing a major component. Bug: https://bugs.gentoo.org/910168 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> kde-apps/kdegraphics-meta/kdegraphics-meta-23.08.49.9999.ebuild | 4 ++-- kde-apps/kdegraphics-meta/kdegraphics-meta-9999.ebuild | 4 ++-- kde-apps/kdegraphics-meta/metadata.xml | 1 + 3 files changed, 5 insertions(+), 4 deletions(-)
(In reply to Larry the Git Cow from comment #3) > This makes it at least possible to build the meta without pulling in > kde-plasma/kpipewire, even if that means losing a major component. thanks ... well, actually, I find it quite nice to have something in between pulling everything by the metapackages and having to select all packages individually (In reply to Andreas Sturmlechner from comment #1) > No plans until such an option exists upstream. ... and there are no volunteers to bring that upstream, right? :-/
(In reply to kavol from comment #4) > (In reply to Larry the Git Cow from comment #3) > > This makes it at least possible to build the meta without pulling in > > kde-plasma/kpipewire, even if that means losing a major component. > > thanks ... well, actually, I find it quite nice to have something in between > pulling everything by the metapackages and having to select all packages > individually I'm already questioning the usefulness of that flag since sys-apps/xdg-desktop-portal will hard-depend on PipeWire on next version bump.
(In reply to Andreas Sturmlechner from comment #5) > I'm already questioning the usefulness of that flag since > sys-apps/xdg-desktop-portal will hard-depend on PipeWire on next version > bump. WTH :-( I even haven't noticed this is pulled as dependency ... so, can we continue by dropping the hard dependency on the desktop-portal?
(In reply to kavol from comment #6) > (In reply to Andreas Sturmlechner from comment #5) > > I'm already questioning the usefulness of that flag since > > sys-apps/xdg-desktop-portal will hard-depend on PipeWire on next version > > bump. > so, can we continue by dropping the hard dependency on the desktop-portal? How should that work if not by wishful thinking?
don't know, by explaining to the relevant devels that really not everyone needs this flatpack stuff?
It is not about flatpak at all.
(In reply to Andreas Sturmlechner from comment #9) > It is not about flatpak at all. pardon my ignorance, but ... https://github.com/flatpak/xdg-desktop-portal A portal frontend service for Flatpak and other desktop containment frameworks. ^ how is that "not about flatpak at all"? from my understanding, this is just another abstraction layer that is completely useless when compiling from source and running apps natively without any sandboxing or could you tell me why would I need it if I don't use Flatpak (or similar, for that matter)?
It's needed for screensharing on Wayland in general. Anyway, we're not the people to convince. Feel free to send a patch upstream.
