I don't use chromium and I don't know what release cycle it has, but can't those interested in running chromium use an ebuild that tracks the git tree and updates after every change. The maintenance burden would be minimal, and any patches could be applied with /etc/portage/patches. If something like this isn't suitable for ::gentoo, it can be added to a personal overlay. If the upstream release cycle is too fast, someone could fork the repo and update the fork as slow as desired. Maybe something like this: # Copyright 1999-2023 Gentoo Authors # Distributed under the terms of the MIT License
EAPI=8 DESCRIPTION="The chromium browser" HOMEPAGE="https://github.com/chromium/chromium"; EGIT_REPO_URI="https://github.com/chromium/chromium.git"; inherit git-r3 LICENSE="BSD-3" SLOT="0" KEYWORDS="~amd64 ~x86" IUSE="" DEPEND="|| ( sys-devel/gcc sys-devel/clang )" RDEPEND="${DEPEND}" BDEPEND="" src_configure() { chromium_configure } src_install() { chromium_compile mv out/Release/chromedriver{.unstripped,} || die rm -f out/Release/locales/*.pak.info || die # Build manpage; bug #684550 sed -e 's|@@PACKAGE@@|chromium-browser|g; s|@@MENUNAME@@|Chromium|g;' \ chrome/app/resources/manpage.1.in > \ out/Release/chromium-browser.1 || die # Build desktop file; bug #706786 sed -e 's|@@MENUNAME@@|Chromium|g; s|@@USR_BIN_SYMLINK_NAME@@|chromium-browser|g; s|@@PACKAGE@@|chromium-browser|g; s|\(^Exec=\)/usr/bin/|\1|g;' \ chrome/installer/linux/common/desktop.template > \ out/Release/chromium-browser-chromium.desktop || die # Build vk_swiftshader_icd.json; bug #827861 sed -e 's|${ICD_LIBRARY_PATH}|./libvk_swiftshader.so|g' \ third_party/swiftshader/src/Vulkan/vk_swiftshader_icd.json.tmpl > \ out/Release/vk_swiftshader_icd.json || die } Also, with all this discussion, one can't help but wonder, is firefox/librewolf also in such danger? On Wed, Jun 7, 2023 at 7:49 PM Mike Gilbert <flop...@gentoo.org> wrote: > On Wed, Jun 7, 2023 at 3:25 PM Jeff Gazso <jeff.ga...@gmail.com> wrote: > > > > That does sound painful. > > > > > - Across the 3 channels, you are looking at roughly 12 releases per > month. > > > That's a lot of churn. > > > > * Why build unstable stuff, why not build only stable releases and fix > the > > problems once? > > That's certainly an option. The downside is stable releases almost > always fix security issues, so you are "under the gun" at that point. > > > * Looking at chromium-browser-official and the GitHub mirror, it's > unclear to > > me which release is stable. How is that sorted out? > > Some links for you: > > https://chromiumdash.appspot.com/releases?platform=Linux > https://chromereleases.googleblog.com/ > > > > - Upstream likes to use modern C++ features, and they write C++ code > that > > > tends to break or is unsupported on stable releases of GCC and LLVM. > > > > * How common of a problem is the C++ issue? > > There are usually some issues with every major Chromium version. > > > * I don't know C++, is that a major obstacle? > > Yes; you would at least need to teach yourself enough of the language > to attempt to interpret compiler error message. > > > > - Upstream bundles many libraries. The Gentoo ebuild has some logic to > > > unbundle a number of these, but maintaining it is a pain. > > > > * What tends to go wrong? > > - Version mismatches: upstream expects a different version of the > library than we have stable on Gentoo. > - Custom patching: sometimes Chromium forks/patches the bundled > library and there is a delay in sending those changes upstream (if it > ever happens). > - Chromium source files sometimes refer to the bundled header files > directly (#include "third_party/mylib/mylib.h") instead of using a > generic path like #include <mylib.h>. > > > > - Using the bundled libraries sometimes is problematic, especially on > > > non-x86-64 targets which upstream doesn't support well. > > > > * What tends to break here? > > For example, take ffmpeg. The bundled library uses a pre-configured > copy of ffmpeg, which can break depending on the user's system. At a > minimum, we need to reconfigure the bundled ffmpeg to work properly. > > > * Is the upstream likely to take patches or are we stuck maintaining a > patch > > set for pretty much all non-x86-64 targets? > > Upstream supports x86-64 and ARM only. All other targets require > distro patching. > > > * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make > > their way upstream? > > Yes, this is why we have a PPC64 patchset (which we mostly steal from > Raptor Computing). > >
