[oe] [meta-xfce][PATCH] xfce4-panel: fix QA issue 'installed-vs-shipped'

[Khem Raj]

On Tue, Jun 19, 2018 at 2:53 AM Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Mon, 2018-06-18 at 19:25 -0400, Mark Asselstine wrote:
> > On Mon, Jun 18, 2018 at 6:27 PM, Andreas Müller <schnitzeltony at gmail.
> > com> wrote:
> > > On Mon, Jun 18, 2018 at 11:42 PM, Richard Purdie
> > > <richard.purdie at linuxfoundation.org> wrote:
> > > Off-Topic / FYI for me gmail considered your email spam
> > > >
> > > > Removing the libtool files became the project default a while ago
> > > > (Jan
> > > > 2017):
> > > >
> > > > meta/conf/distro/defaultsetup.conf:INHERIT_DISTRO ?= "debian
> > > > devshell sstate license remove-libtool"
> > > >
> > > > so I suspect you're in the minority not using that now.
> > >
> > > Maybe true. But breaking builds consumes resources on many sides -
> > > this thread is a good example
> > > >
> > > > http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/conf/distro
> > > > /defaultsetup.conf?id=3e2a47fdfceccd5f8832235b7a2df83076e84a98
> > > >
> > >
> > > The more I think about this:
> > >
> > > * Why is remove-libtool something a distro can override? If causing
> > > trouble it can be deactivated recipe-wise.
> >
> >
> > That was my feeling as well as we were having this discussion,
> > without digging into the history it felt as if this should have been
> > made core functionality and not optional, especially given the
> > opportunity for recipes to opt out. At any rate I am about to send a
> > commit to get things buildable for when the 'remove-libtool' distro
> > feature is absent and as long as it remains optional I suppose all
> > recipes should function with and without the feature.
>
> There are many different features which "distro maintainers" can turn
> on/off which can break the builds. I was always reluctant to add the
> libtool change but we reached the point where it simply no longer made
> sense to keep those files around, they caused more problems than it was
> worth effort for.
>
> Its not a setting I'd recommend anyone use now because as you're
> finding, the .la handling metadata is bitrotting. As with many things
> in the project, its "at your own risk and maintenance burden". Its not
> a combination I have any plans to add tests for.
>
> The better solution would be to drop all the .la file FILES directives
> and handle .la files in a similar way to the way we handle debug files
> into -dbg packages. If anyone cares at this point.
>

Not worth the effort IMO

>
> Cheers,
>
> Richard
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>