Hi Mark On Mon, Jun 18, 2018 at 11:55 AM Mark Hatle <[email protected]> wrote: > > On 6/18/18 1:47 PM, Khem Raj wrote: > > On Mon, Jun 18, 2018 at 11:09 AM Mark Asselstine > > <[email protected]> wrote: > >> > >> On Mon, Jun 18, 2018 at 1:57 PM, Khem Raj <[email protected]> wrote: > >>> On Mon, Jun 18, 2018 at 10:54 AM Mark Hatle <[email protected]> > >>> 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 -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
