Created attachment 444976 [details] Proposed chrome-binary-plugins.ebuild Currenty Google Chrome handle libwidevinecdmadapter.so from it own instead chrome-binary-plugins, there is a reason? This would broke any compatibility support with other chromium implementations and doesn't make any sense if already chrome-binary-plugins is handling binary files. For now, QtWebEngine can support perfectly chrome-binary-plugins with 2 changes, those are: 1: Replace chrome-binary-plugins installation path from /usr/<lib-arch>/chromium-browser to /usr/<lib-arch>/chromium following Suse architecture as explained in QtWebEngine: https://github.com/qt/qtwebengine/blob/dev/src/core/content_client_qt.cpp, not sure if that brokes Chromium, but assuming other distro does it, should be compatible. 2: Provide libwidevinecdmadapter.so from chrome-binary-plugins instead chromium. I think this solution is clear to split binary with opensource project. I don't see the idea of handling closedsource plugins in both ebuilds. Point 1 relates to mainainer of www-plugins/chrome-binary-plugins, point 2 relates to maintainer of www-client/chromium If those 2 proposal can be done, the availability of Widevine would be natural for QtWebEngine without any recompilation if compiled with bindist. Attaching a proposal of chrome-binary-plugins ebuild. Due Chromium ebuild complexity, I prefer to be analyzed by mainainer.
So 3 distros install it in 3 difference places. Wonderful.
Given that chrome on Linux is moving toward managing plugins via the component updater, chrome-binary-plugins is probably not going to work in a few months.
In other words, for Chromium is not longer needed the package chrome-binary-plugins because the component manager is handling it? In that case, is just fine if we modify chrome-binary-plugins in that way? I can't really test chromium because take me too much compilation time and CPU resources. We have currently two options. 1) Modifying with patches the path of QtWebEngine to match the current one and include libwidevinecdmadapter.so from Google Chrome, a very bad idea from my opinion. 2) Modify chrome-binary-plugins to include libwidevinecdmadapter.so, remove it from Chromium (as suggested) and one of the following: a) Update Chromium to use the path of /usr/lib<arch>/chromium and change the plugins path. b) Update QtWebEngine to use current /usr/lib<arch>/chromium-browser. c) Make symlinks of NoCL plugins into both /usr/lib<arch>/chromium-browser and /usr/lib<arch>/chromium d) Ugliest and less intrusive solution, make a different ebuild just for /usr/lib<arch>/chromium, who blocks chrome-binary-plugins ebuild to avoid problems. I would like to discard number one because would be very hard to maintain.
commit c52485a2413414510b9239a0b8e89bae5834c18d Author: Mike Gilbert <floppym@gentoo.org> Date: Mon Sep 5 00:52:23 2016 -0400 www-plugins/chrome-binary-plugins: change install location Install in /usr/lib64/chromium, where they may be detected by QtWebEngine. Bug: https://bugs.gentoo.org/592896 Package-Manager: portage-2.3.0_p24 .../chrome-binary-plugins-53.0.2785.92.ebuild | 7 ++++--- .../chrome-binary-plugins-53.0.2785.92_beta.ebuild | 9 +++++---- .../chrome-binary-plugins-54.0.2840.8_alpha.ebuild | 6 +++--- 3 files changed, 12 insertions(+), 10 deletions(-)
Created attachment 445356 [details] Changes to ebuild to allow build without gnome
(In reply to Mike Lothian from comment #5) > Created attachment 445356 [details] > Changes to ebuild to allow build without gnome Wrong bug report.
