[OE-core] [PATCH] pango: add PACKAGECONFIGs for all the optional dependencies

Ross Burton ross.burton at intel.com
Tue Oct 8 11:01:35 UTC 2019


On 07/10/2019 18:44, Randy MacLeod wrote:
> PACKAGECONFIG has been nagging at me for years.
> This is mostly me just blowing off steam but I would
> like to hear your opinion.
> 
> While this is technically correct and seeing as oe-core is
> a distribution building system rather than a distro, this change
> makes sense, I do wonder how we're going to keep up with
> the testing that such flexibility requires. We could
> test each package's default config and then toggle each
> PACKAGECONFIG individually, hopefully with an automated tool.

I don't believe an automated tool for this makes complete sense, as 
several recipes have mutually exclusive PACKAGECONFIGs options. 
Building all of the combinations will by design fail some of the time, 
and that's not even considering other recipes where recipe A may depend 
on recipe B having PACKAGECONFIG foo enabled.

This tooling existing would be useful to easily verify a recipe instead 
of having to do it by hand, but I don't believe it should be part of the 
automated QA process.

> The status quo seems to be that we enable the options, pick
> reasonable defaults, and hope that distros and users test their
> configs and report errors. That'll work for detecting some errors
> even if it can take a while to get feedback. We recently tested
> a variety of configurations and found > 30 configurations that
> didn't work at all at build time.
> 
> So for this package, are there use cases that you know of where
> the old, hard-coded defaults are a problem?

I added the PACKAGECONFIGs for this package because there were some 
already but they didn't cover the range of optional dependencies, and 
most of the dependencies are for the tools and test suite.  If someone 
was slimming a system aggresively, they could disable the bulk of the 
PACKAGECONFIGs and still have a usable harfbuzz library.

There's definitely a balance between flexibility and complication. For 
example, I recently encouraged removal of some PACKAGECONFIGs for 
optional dependencies that have been dead for several years.

> It's also interesting to see that the README.md for pango says:
> 
>     The Cairo backend is the preferred backend to use Pango with and is
>     subject of most of the development in the future.  It has the
>     advantage that the same code can be used for display and printing.
> 
>     We suggest using Pango with Cairo as described above, but ...
> 
> so it would seem that even our defaults are not the ones recommended
> by upstream.
> 
> Does pango build if you drop glib? The README.md says:
>     Dependencies
>     ------------
>     Pango depends on the GLib library; more information about GLib can
>     be found at https://www.gtk.org/.

So there's a little confusion here in that I put "pango" in the commit 
message but the patch was for harfbuzz... v2 incoming.

Our Pango, however, is built with Cairo and Glib (not as a 
PACKAGECONFIG, but explicit DEPENDS).

Ross


More information about the Openembedded-core mailing list