[oe] chromium detected as stripped

[Khem Raj]

On 8/15/17 7:43 AM, Trevor Woerner wrote:
> 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.
> 

musl is supported in oe-core, meta-musl is practically dead since then
and you do not need meta-musl for musl anymore, I guess a README update
for meta-musl will be a good thing to reflect that. We have fixed
packages in libc agnostic ways where possible. Most of time musl patches
have landed upstream into respective packages and process is still on
chromium will be no different moreover there are many distros beyond OE
ones which use musl as default C library, many of these patches are
shared with them. When we support a common package, and it enables
certain OE-core feature then it belongs to that package itself.

I understand your reluctance since you might not be using musl, however
commonly maintained patchset is far less burden with little extra effort
thats the mantra we follow, otherwise oe-core would never work on so
many arches and libcs.