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:


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

Reply via email to