[oe] chromium detected as stripped

Trevor Woerner twoerner at gmail.com
Tue Aug 15 14:43:07 UTC 2017


On Tue, Aug 15, 2017 at 9:05 AM, Raphael Kubo da Costa
<raphael.kubo.da.costa at intel.com> wrote:
> The main reason why I opted to start my recipe from scratch at the time
> was simplicity: the meta-browser repository used the same recipe for
> Chromium, CEF and Chromium with Ozone-Wayland, offered many different
> options and shipped quite a few patches that made updates quite
> difficult.

I agree 100% (or more). This is why, earlier this year, I removed CEF
(which wasn't working, hadn't been working in over a year, and
(apparently) nobody was using). This is also why I also split out
"pure" chromium and chromium-wayland recipes. Trying to do everything
in one recipe was getting too onerous.

In my own (failed and therefore put on the back-burner) efforts to
update the chromium (x11) recipe to 59 and 60 I too created a recipe
from scratch without all the baggage of debug vs non-debug, no
packageconfigs, multiple architectures, component build, and without
pulling in any *.inc files. Just a small, self-contained recipe.

> My recipe is a lot less customizable, but OTOH that makes it
> quite easy to move to new Chromium milestones. If we're able to find a
> balance there, I definitely think we'd be able to get a lot more done
> together.

I think it was a mistake for meta-browser to have recently added a
huge number of patches supporting musl. One commit alone added almost
700 lines of diff for musl support (not to mention the subsequent
fixup patches)! Musl support should be kept and maintained in
meta-musl, isn't that the purpose of meta-musl? If users want musl
support they're going to need to add meta-musl anyway, so it's no
change from a user's point of view. But 700 lines of patches provides
a heavy burden for anyone trying to maintain or update meta-browser's
chromium, especially if they don't use or care about musl support.



More information about the Openembedded-devel mailing list