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

[Martin Jansa]

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.

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.

> > No I don't like that meta-qt5 has to use own bbappend for gstreamer,
> > it's necessary in this case because of the paths as you sad, but also
> > causes:
> > https://github.com/meta-qt5/meta-qt5/commit/73f99f2370a3dc5b81f42d0af7fe530431599454
> > which is quite annoying for meta-qt5 users, because this is one of very
> > few reasons why different meta-qt5 version isn't compatible with
> > different oe-core. So in order to use Qt 5.11 with oe-core from morty, I
> > need to BBMASK this bbappend and create the old one for
> > gstreamer1.0-plugins-bad in our project layer, it would be much nicer
> > and less error prone with PACKAGECONFIG directly in oe-core.
> 
> Agreed. This is a drawback. Unavoidable in this case, unfortunately.
> 
> > Also if you look at EXTRA_OECONF you'll see either --disable-qt twice or
> > --disable-qt followed by --enable-qt (when we depend on configure to let
> > the last option on command line win) which isn't ideal as well and might
> > confuse people looking at the log.do_configure.
> 
> Hmm perhaps a bit, but the order matters, so I know that the last one 
> "wins". Multiple switches like that are not uncommon in automated build 
> environments, so I am used to seeing these.

Congrats! but it still doesn't mean we should add more of them without
good reasons, right?
 
> >> I suppose with libvisual such a central packageconfig would work, but
> >> isn't the whole idea of oe-core to be lean? And yet, now we start adding
> >> more and more packageconfigs even though the recipes are in some other
> >> layers that are not part of the central ones (oe-core and
> >> meta-openembedded)?
> > Yes it's supposed to be lean as in number of recipes it needs to carry,
> > not lean by number of lines (PACKAGECONFIG is 1 line exactly as the
> > --diable flag in EXTRA_OECONF) or lean in number of ways how people are
> > able to use it.
> >
> > Why should meta-openembedded have special status for PACKAGECONFIGs
> > anyway, if you want to make it harder to customize the build, why stop
> > there?
> 
> meta-openembedded isn't tied to any particular platform, BSP, distro, 
> environment. It does have a special place, since it is a central layer 
> for many setups. How many BSP layers, distro layers etc. list both 
> oe-core and meta-openembedded as dependency, for example? meta-debian 
> and meta-qt5-extra however do not have nearly the same status (and these 
> are the places where libvisual is).

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?

> >> You might as well add dozens of packageconfigs to
> >> gstreamer1.0-plugins-bad, just in case some obscure layer adds a recipe
> >> for OpenEXR or spandsp for example.
> > Yes, that's exactly what I often do, last time e.g. with libdrm
> > http://git.openembedded.org/openembedded-core/commit/?id=dc7d3b2ff79ae324b96a51ec1be557a432ed351d
> > and e.g. qemu before that, adding PACKAGECONFIG for dependencies which
> > I haven't submitted to meta-networking yet at that time:
> > http://git.openembedded.org/openembedded-core/commit/?id=ebb6ef1dbc7e03a4b7030b3056bd0fa59fdd047b
> > and I haven't submitted the recipe for virglrenderer yet as well and
> > I don't see any issue with having the PACKAGECONFIG for it already.
> >
> 
> 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.

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/0544c067/attachment-0002.sig>