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

[Khem Raj]

Hi Mark

On Mon, Jun 18, 2018 at 11:55 AM Mark Hatle <mark.hatle at windriver.com> wrote:
>
> On 6/18/18 1:47 PM, Khem Raj wrote:
> > On Mon, Jun 18, 2018 at 11:09 AM Mark Asselstine
> > <mark.asselstine at windriver.com> wrote:
> >>
> >> On Mon, Jun 18, 2018 at 1:57 PM, Khem Raj <raj.khem at gmail.com> wrote:
> >>> On Mon, Jun 18, 2018 at 10:54 AM Mark Hatle <mark.hatle at windriver.com> wrote:
> >>>>
> >>>> On 6/18/18 12:50 PM, Khem Raj wrote:
> >>>>> Hi Mark
> >>>>>
> >>>>> It seems your distro is not inheriting it globally. Here I have
> >>>>> INHERIT_DISTRO ?=  "debian devshell sstate license remove-libtool"
> >>>>
> >>>> So is remove-libtool a recipe or a distro option?
> >>>>
> >>>> I'm asking because doing this half-way is causing a lot of confusion.
> >>>>
> >>>> If it's a distro option, then the recipes should work without it being set.  If
> >>>> it's a recipe option, then the recipes that need it should use it.
> >>>>
> >>>> Right now it doesn't seem to be working with these recipes because they don't
> >>>> package the .la files UNLESS it's enabled.  So the fix is either to package them
> >>>> (by default) or inherit the remove-libtool.
> >>>>
> >>>
> >>> since we make it as part of meta/conf/distro/defaultsetup.conf
> >>> its a default policy,  its perfectly fine for a distro to disregard that
> >>> however, then you fall into a non-default case. I am willing to accept
> >>> per recipe patches but I would recommend to consider it as a distro
> >>> feature for your distro.
> >>>
> >>
> >> Andreas,
> >>
> >> Can you revert your "various classes recipes: Remove FILES entries for
> >> dbg/dev packages" then? If this is a distro feature then these recipes
> >> need to build without the QA issue and without the remove-libtool
> >> distro feature being set.
> >
> > This is in default features so I would not recommend revert, distros
> > not using this feature are in best position to fix it, as I said
> > before those patches are acceptable.
> >
>
> I'm confused.  If you say it's a default option, and if you DON'T use it, then
> you are responsible for fixing this.  I take that as you want patches to fix the
> issue.

I want to encourage folks to use the default distro policy as much as possible.

>
> The revert will return the original code that packages the .la files (if they
> exist) and is the 'patch'.
>
> Right now we have a broken situation where it doesn't work, and a ton of
> .bbappends would be needed for a custom distro, and these bbappends would make
> it difficult to pass a Yocto Project compliance test.
>

I understand that, thats where I said, patches are acceptable to fix
the fallouts for
custom distros but we should not block.

> (I don't really care either way if someone includes or doesn't .la files in a
> distribution -- just that since it's even an option -- both sides of the option
> should work.  I'm also fine with saying OE only tests one side of the option,
> but that means patches should be accepted for the other side.)
>
> --Mark