[OE-core] [PATCH v2 1/6] gstreamer1.0-plugin-base: Update packageconfigs

Thu Jul 19 14:02:34 UTC 2018

On Thu, Jul 19, 2018 at 03:38:16PM +0200, Carlos Rafael Giani wrote:
> The main problem I see with all of this - aside from filling the recipes 
> with packageconfigs that may or may not become actually usable in the 
> future - is that when the packageconfig recipes don't yet exist, you are 
> essentially speculating. Even the *names* of the dependencies may turn 
> out to be different in the future (foo vs. libfoo for example). Or 
> perhaps you need to include more dependencies, like what can happen with 
> OpenGL ES (it also needs libEGL).
> 
> 
> On 2018-07-19 15:20, Martin Jansa wrote:
> > On Thu, Jul 19, 2018 at 02:47:58PM +0200, Carlos Rafael Giani wrote:
> >>
> >> On 2018-07-19 14:12, Martin Jansa wrote:
> >>> On Thu, Jul 19, 2018 at 01:16:51PM +0200, Carlos Rafael Giani wrote:
> >>>> As a general rule, I think adding packageconfigs to an oe-core recipe
> >>>> that has dependencies outside of oe-core and meta-openembedded is
> >>>> questionable. Take the qt5 packageconfig for example. It is *not* part
> >>>> of gstreamer1.0-plugins-good in oe-core, and for good reason - it needs
> >>>> extra switches for passing paths to moc, uic etc.
> >>> I don't see what's questionable with that. PACKAGECONFIG is just a way
> >>> to pass configure options like EXTRA_OECONF just with benefit that it's
> >>> easily switched from outside and that it encapsulates build time and
> >>> runtime dependencies together with the options.
> >>>
> >>>> Now, what if a recipe outside of oe-core and meta-openembedded is just
> >>>> like that? It needs its own customizations, its own switches. It would
> >>>> be better off setting up its own packageconfig, just like what that
> >>>> bbappend in meta-qt5 does.
> >>> If someone submits PACKAGECONFIG addition for something which only
> >>> exists in his own layer, I'm fine with that, why should we make it
> >>> harder for people to use oe-core or meta-oe recipes?
> >> Adding a .bbappend that adds the packageconfig does not sound hard to
> >> me. However, having packageconfigs whose dependencies may or may not be
> >> dead (because of the layer being dead) sounds more like a maintenance
> >> problem.
> > It's not too hard, but completely unnecessary when the PACKAGECONFIG was
> > already there in oe-core and you're removing it for no good reason.
> > Especially if such PACKAGECONFIG needs to be added by multiple people in
> > multiple projects instead of just once in the recipe where it belongs.
> 
> libvisual is not in oe-core or meta-openembedded, otherwise I would have 
> added it. As for zlib etc. I already added them back in in v2 of the 
> patches.

But you're still _removing_ the PACKAGECONFIG for libvisual.

> > And it brings annoying issues like the gstreamer bbappend in meta-qt5
> > without any good reason.
> >
> > Carrying libdrm PACKAGECONFIGs in my bbappend was simple enough, but
> > then Ross migrated libdrm from autotools to meson and instead of simply
> > updating the PACKAGECONFIGs to the format used by meson atomically with
> > the meson migration in the same commit I had to update the .bbappend,
> > which caused my layer to require new oe-core again (to have the meson
> > migration, because the PACKAGECONFIG isn't backwards compatible) and at
> > that time I've rather submitted all my PACKAGECONFIGs to oe-core instead
> > of maintenance burden to keep them locally.
> 
> As said, I can then agree to add packageconfigs for recipes that already 
> exist somewhere. But adding them speculatively with not-yet-existing 

Except you can never know what exists elsewhere, because not all layers
are public or on layerindex.

> dependencies is an entirely different matter. I wouldn't do that. 
> Instead, I'd keep the --disable-twolame etc. switches around.
> 
> > Congrats! but it still doesn't mean we should add more of them without
> > good reasons, right?
> 
> Sure, but avoiding them is not a high priority for me. They are more of 
> an annoyance than an outright problem.
> 
> 
> > And what about people who have libvisual in their layer (from
> > meta-debian or meta-qt5-extra or written from scratch) are they also now
> > responsible for maintaining bbappend PACKAGECONFIG for gstreamer?
> 
> Yeah, at least initially. If some layer introduces a recipe that happens 
> to have a corresponding plugin in base/good/bad/ugly, it makes sense to 
> add a .bbappend at first. Later on, you can patch oe-core if it sounds 
> like having this packageconfig in a central place makes sense. To me, 
> this sounds like a more modular approach.
> 
> 
> >> Eh, I don't think I can agree with that approach. Having an openexr
> >> packageconfig for example implies that this packageconfig is actually
> >> usable and gstreamer1.0-plugins-bad can be built with it enabled. But
> >> adding it without an openexr dependency? Sounds broken to me. This is
> >> why I prefer to keep such features disabled until there is a recipe for
> >> them in meta-openembedded.
> > It's not broken, it just isn't well tested. Everybody tests only the
> > explicitly disabled path until someone actually tries to enable it,
> > which is exactly the same for disabled PACKAGECONFIG and --disable-foo
> > in EXTRA_OECONF.
> >
> > I'm not saying that these features should be enabled! Of course not,
> > they cannot be for features which require extra dependencies from other
> > layers. I'm just saying that --disable-twolame from
> > PACKAGECONFIG[twolame] is much better than --disable-twolame from
> > EXTRA_OECONF, because is easy to enable without the .bbappend and in
> > most cases it will work if you provide necessary dependencies or show
> > reasonable error showing what you need to provide.
> >
> 
> It is not about them being enabled, but about what happens if someone 

you said "why I prefer to keep such features disabled" in previous
e-mail.

> sees these packageconfigs and tries to enable them. Then, oops, they 
> don't work, because the dependency is non-existent. So, if this 
> packageconfig _cannot_ work because the dependency doesn't exist yet 
> anywhere in any layer, why is this packageconfig there in the first place?

Because it's our best shot on making it configure-able, if someone names
the dependency differently, then the PACKAGECONFIG can be improved later
or that extra dependency can get PROVIDES with the name used in
PACKAGECONFIG. But that's still closer to usable than

EXTRA_OECONF_remove = "--disable-foo"
EXTRA_OECONF_append = " --enable-foo"
DEPENDS_append = " foo"
RDEPENDS_${PN}_append = " foo-utils"

or adding PACKAGECONFIG in bbappend and ending with --disable-foo
followed by --enable-foo in EXTRA_OECONF.

> For example, the libneon recipe got removed because upstream is dead. 
> Would you still keep its packageconfig around just in case someone 
> decides to bring back the recipe for their own personal layer?
> (Ironically, I just noticed that I made a mistake by _not_ removing the 
> neon packageconfig while still adding --disable-neon to EXTRA_OECONF ..)

Yes, I would keep PACKAGECONFIG for it, because for most people it will
result in the same --disable-neon and for someone who had neon
PACKAGECONFIG enabled before it will work after bringing back just the
libneon recipe (without reinventing PACKAGECONFIG knob in gstreamer
bbappend).

I don't want to continue in this discussion, hopefully someone else will
add an opinion as well.

Cheers,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180719/b779f006/attachment-0002.sig>