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).
