Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
[Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes] On 17.02.24 (Fri 21:51) Martin Jansa wrote: > OK, should I update all currently PNBLACKLISTed recipes to add " - the > recipe will be removed on 2017-09-01 unless the issue is fixed" in the > PNBLACKLIST value, so that we can delete all blacklisted recipes > before 2.4 release? I haven't seen any additional discussion on this yet but my personal opinion on this is it seems reasonable to draw a line in the sand and one that's quite far out. I also expect that there'll be a flurry of activity as the deadline draws close, so there's room for flexibility in the drop-dead date, but that'd be a discretionary thing. If we wanted to be slightly less contentious, the wording could be 'may' rather than 'will' and then the message is "if it isn't fixed by this date, it's fair game to be removed whenever someone gets around to it". -J. > > On Fri, Feb 24, 2017 at 9:39 PM, Philip Balister <phi...@balister.org> wrote: > > On 02/24/2017 01:16 AM, Martin Jansa wrote: > >> If nobody speaks up within some > > amount of time the maintainer considers reasonable (I'm thinking a Yocto > > release > > cycle) then it's fair game to remove the recipe in question. > > > > Maybe this is different case with at least some PNBLACKLIST entries we > > currently have, but > > I don't remove PNBLACKLISTed recipes, because as we discussed it's > always > > easier to unblacklist > > recipe from e.g. DISTRO config if the issue doesn't affect you for > whatever > > reason and causes > > less churn in the metadata when it gets unblacklisted. > > > > And many PNBLACKLISTed recipes are also abandonware. > > > > I think we need to use a different "flag" for recipes that need > updating, and have maintained upstreams from recipes that have upstreams > that are abandoned. > > So blacklist broken recipes with good upstreams and deprecate recipes > with dead upstreams. > > Philip > > > > > So my question is, if we will remove PNDEPRECATed recipes after one > cycle, > > should we start > > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both > > cases it might backfire > > when someone will fail to find recipe for his favorite abandonware and > will > > try to add completely > > new recipe for it, or we see someone restoring these recipes (e.g. in > own > > layers instead of fixing > > the PNBLACKLIST/PNDEPRECATED reasons in original layer). > > > > On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj <raj.k...@gmail.com> wrote: > > > >> > >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald > <joe_macdon...@mentor.com> > >> wrote: > >> > >>> Based on the blacklist behaviour, recipes can be tagged as deprecated. > >>> Such recipes will produce a warning message when included in a build > but > >>> unlike blacklisted recipes, the build will continue. > >> > >> > >> Perhaps this should also be documented in manuals > >> > >>> > >>> > >>> Signed-off-by: Joe MacDonald <joe_macdon...@mentor.com> > >>> --- > >>> > >>> I threw this together a long time ago and never got around to sending > it > >>> out for > >>> consideration, but after the excitement last week and this, I got > >>> thinking about > >>> it again and thought it might be useful. My specific use-case for > this > is > >>> recipes I see in meta-networking that I know are largely abandonware > but > >>> that I > >>> don't want to completely throw out without giving some kind of heads > up. > >>> Obviously this is purely informational, there's no mechanism set up > for > >>> purging > >>> deprecated recipes, that's intended to be a maintainer activity, but > the > >>> idea > >>> would be that the maintainer would flag a recipe as deprecated > (probably > >>> when > >>> it's become more trouble than it seems to be worth) and thereafter > users > >>> would > >>> have fair warning that this thing is on notice. If nobody speaks up > >>> within some > >>> amount of
Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
OK, should I update all currently PNBLACKLISTed recipes to add " - the recipe will be removed on 2017-09-01 unless the issue is fixed" in the PNBLACKLIST value, so that we can delete all blacklisted recipes before 2.4 release? On Fri, Feb 24, 2017 at 9:39 PM, Philip Balisterwrote: > On 02/24/2017 01:16 AM, Martin Jansa wrote: > >> If nobody speaks up within some > > amount of time the maintainer considers reasonable (I'm thinking a Yocto > > release > > cycle) then it's fair game to remove the recipe in question. > > > > Maybe this is different case with at least some PNBLACKLIST entries we > > currently have, but > > I don't remove PNBLACKLISTed recipes, because as we discussed it's always > > easier to unblacklist > > recipe from e.g. DISTRO config if the issue doesn't affect you for > whatever > > reason and causes > > less churn in the metadata when it gets unblacklisted. > > > > And many PNBLACKLISTed recipes are also abandonware. > > > > I think we need to use a different "flag" for recipes that need > updating, and have maintained upstreams from recipes that have upstreams > that are abandoned. > > So blacklist broken recipes with good upstreams and deprecate recipes > with dead upstreams. > > Philip > > > > > So my question is, if we will remove PNDEPRECATed recipes after one > cycle, > > should we start > > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both > > cases it might backfire > > when someone will fail to find recipe for his favorite abandonware and > will > > try to add completely > > new recipe for it, or we see someone restoring these recipes (e.g. in own > > layers instead of fixing > > the PNBLACKLIST/PNDEPRECATED reasons in original layer). > > > > On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj wrote: > > > >> > >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald > > >> wrote: > >> > >>> Based on the blacklist behaviour, recipes can be tagged as deprecated. > >>> Such recipes will produce a warning message when included in a build > but > >>> unlike blacklisted recipes, the build will continue. > >> > >> > >> Perhaps this should also be documented in manuals > >> > >>> > >>> > >>> Signed-off-by: Joe MacDonald > >>> --- > >>> > >>> I threw this together a long time ago and never got around to sending > it > >>> out for > >>> consideration, but after the excitement last week and this, I got > >>> thinking about > >>> it again and thought it might be useful. My specific use-case for > this is > >>> recipes I see in meta-networking that I know are largely abandonware > but > >>> that I > >>> don't want to completely throw out without giving some kind of heads > up. > >>> Obviously this is purely informational, there's no mechanism set up for > >>> purging > >>> deprecated recipes, that's intended to be a maintainer activity, but > the > >>> idea > >>> would be that the maintainer would flag a recipe as deprecated > (probably > >>> when > >>> it's become more trouble than it seems to be worth) and thereafter > users > >>> would > >>> have fair warning that this thing is on notice. If nobody speaks up > >>> within some > >>> amount of time the maintainer considers reasonable (I'm thinking a > Yocto > >>> release > >>> cycle) then it's fair game to remove the recipe in question. > >>> > >>> meta/classes/deprecated.bbclass| 16 > >>> meta/conf/distro/defaultsetup.conf | 3 ++- > >>> 2 files changed, 18 insertions(+), 1 deletion(-) > >>> create mode 100644 meta/classes/deprecated.bbclass > >>> > >>> diff --git a/meta/classes/deprecated.bbclass > b/meta/classes/deprecated. > >>> bbclass > >>> new file mode 100644 > >>> index 000..3dcdadb > >>> --- /dev/null > >>> +++ b/meta/classes/deprecated.bbclass > >>> @@ -0,0 +1,16 @@ > >>> +# To use the deprecated recipe check, a distribution should > >>> +# include this class in the INHERIT_DISTRO > >>> +# > >>> +# Features: > >>> +# > >>> +# * To add a package to the deprecated list, set: > >>> +# PNDEPRECATED[pn] = "message" > >>> +# > >>> + > >>> +addtask check_deprecated before do_fetch > >>> +python do_check_deprecated () { > >>> +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), > >>> False) > >>> + > >>> +if deprecated: > >>> +bb.warn("Recipe is deprecated: ", (deprecated)) > >>> +} > >>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/ > >>> defaultsetup.conf > >>> index ca2f917..16ece3a 100644 > >>> --- a/meta/conf/distro/defaultsetup.conf > >>> +++ b/meta/conf/distro/defaultsetup.conf > >>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', > >>> '/' + str(d.getVar('MACHINE' > >>> USER_CLASSES ?= "" > >>> PACKAGE_CLASSES ?= "package_ipk" > >>> INHERIT_BLACKLIST = "blacklist" > >>> +INHERIT_DEPRECATED = "deprecated" > >>> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool" > >>> -INHERIT += "${PACKAGE_CLASSES}
Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
On 02/24/2017 01:16 AM, Martin Jansa wrote: >> If nobody speaks up within some > amount of time the maintainer considers reasonable (I'm thinking a Yocto > release > cycle) then it's fair game to remove the recipe in question. > > Maybe this is different case with at least some PNBLACKLIST entries we > currently have, but > I don't remove PNBLACKLISTed recipes, because as we discussed it's always > easier to unblacklist > recipe from e.g. DISTRO config if the issue doesn't affect you for whatever > reason and causes > less churn in the metadata when it gets unblacklisted. > > And many PNBLACKLISTed recipes are also abandonware. > I think we need to use a different "flag" for recipes that need updating, and have maintained upstreams from recipes that have upstreams that are abandoned. So blacklist broken recipes with good upstreams and deprecate recipes with dead upstreams. Philip > So my question is, if we will remove PNDEPRECATed recipes after one cycle, > should we start > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both > cases it might backfire > when someone will fail to find recipe for his favorite abandonware and will > try to add completely > new recipe for it, or we see someone restoring these recipes (e.g. in own > layers instead of fixing > the PNBLACKLIST/PNDEPRECATED reasons in original layer). > > On Fri, Feb 24, 2017 at 5:55 AM, Khem Rajwrote: > >> >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald >> wrote: >> >>> Based on the blacklist behaviour, recipes can be tagged as deprecated. >>> Such recipes will produce a warning message when included in a build but >>> unlike blacklisted recipes, the build will continue. >> >> >> Perhaps this should also be documented in manuals >> >>> >>> >>> Signed-off-by: Joe MacDonald >>> --- >>> >>> I threw this together a long time ago and never got around to sending it >>> out for >>> consideration, but after the excitement last week and this, I got >>> thinking about >>> it again and thought it might be useful. My specific use-case for this is >>> recipes I see in meta-networking that I know are largely abandonware but >>> that I >>> don't want to completely throw out without giving some kind of heads up. >>> Obviously this is purely informational, there's no mechanism set up for >>> purging >>> deprecated recipes, that's intended to be a maintainer activity, but the >>> idea >>> would be that the maintainer would flag a recipe as deprecated (probably >>> when >>> it's become more trouble than it seems to be worth) and thereafter users >>> would >>> have fair warning that this thing is on notice. If nobody speaks up >>> within some >>> amount of time the maintainer considers reasonable (I'm thinking a Yocto >>> release >>> cycle) then it's fair game to remove the recipe in question. >>> >>> meta/classes/deprecated.bbclass| 16 >>> meta/conf/distro/defaultsetup.conf | 3 ++- >>> 2 files changed, 18 insertions(+), 1 deletion(-) >>> create mode 100644 meta/classes/deprecated.bbclass >>> >>> diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated. >>> bbclass >>> new file mode 100644 >>> index 000..3dcdadb >>> --- /dev/null >>> +++ b/meta/classes/deprecated.bbclass >>> @@ -0,0 +1,16 @@ >>> +# To use the deprecated recipe check, a distribution should >>> +# include this class in the INHERIT_DISTRO >>> +# >>> +# Features: >>> +# >>> +# * To add a package to the deprecated list, set: >>> +# PNDEPRECATED[pn] = "message" >>> +# >>> + >>> +addtask check_deprecated before do_fetch >>> +python do_check_deprecated () { >>> +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), >>> False) >>> + >>> +if deprecated: >>> +bb.warn("Recipe is deprecated: ", (deprecated)) >>> +} >>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/ >>> defaultsetup.conf >>> index ca2f917..16ece3a 100644 >>> --- a/meta/conf/distro/defaultsetup.conf >>> +++ b/meta/conf/distro/defaultsetup.conf >>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', >>> '/' + str(d.getVar('MACHINE' >>> USER_CLASSES ?= "" >>> PACKAGE_CLASSES ?= "package_ipk" >>> INHERIT_BLACKLIST = "blacklist" >>> +INHERIT_DEPRECATED = "deprecated" >>> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool" >>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} >>> ${INHERIT_BLACKLIST}" >>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} >>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}" >>> -- >>> 1.9.1 >>> >>> -- >>> ___ >>> Openembedded-core mailing list >>> Openembedded-core@lists.openembedded.org >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>> >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >>
Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
> If nobody speaks up within some amount of time the maintainer considers reasonable (I'm thinking a Yocto release cycle) then it's fair game to remove the recipe in question. Maybe this is different case with at least some PNBLACKLIST entries we currently have, but I don't remove PNBLACKLISTed recipes, because as we discussed it's always easier to unblacklist recipe from e.g. DISTRO config if the issue doesn't affect you for whatever reason and causes less churn in the metadata when it gets unblacklisted. And many PNBLACKLISTed recipes are also abandonware. So my question is, if we will remove PNDEPRECATed recipes after one cycle, should we start removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both cases it might backfire when someone will fail to find recipe for his favorite abandonware and will try to add completely new recipe for it, or we see someone restoring these recipes (e.g. in own layers instead of fixing the PNBLACKLIST/PNDEPRECATED reasons in original layer). On Fri, Feb 24, 2017 at 5:55 AM, Khem Rajwrote: > > On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald > wrote: > >> Based on the blacklist behaviour, recipes can be tagged as deprecated. >> Such recipes will produce a warning message when included in a build but >> unlike blacklisted recipes, the build will continue. > > > Perhaps this should also be documented in manuals > >> >> >> Signed-off-by: Joe MacDonald >> --- >> >> I threw this together a long time ago and never got around to sending it >> out for >> consideration, but after the excitement last week and this, I got >> thinking about >> it again and thought it might be useful. My specific use-case for this is >> recipes I see in meta-networking that I know are largely abandonware but >> that I >> don't want to completely throw out without giving some kind of heads up. >> Obviously this is purely informational, there's no mechanism set up for >> purging >> deprecated recipes, that's intended to be a maintainer activity, but the >> idea >> would be that the maintainer would flag a recipe as deprecated (probably >> when >> it's become more trouble than it seems to be worth) and thereafter users >> would >> have fair warning that this thing is on notice. If nobody speaks up >> within some >> amount of time the maintainer considers reasonable (I'm thinking a Yocto >> release >> cycle) then it's fair game to remove the recipe in question. >> >> meta/classes/deprecated.bbclass| 16 >> meta/conf/distro/defaultsetup.conf | 3 ++- >> 2 files changed, 18 insertions(+), 1 deletion(-) >> create mode 100644 meta/classes/deprecated.bbclass >> >> diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated. >> bbclass >> new file mode 100644 >> index 000..3dcdadb >> --- /dev/null >> +++ b/meta/classes/deprecated.bbclass >> @@ -0,0 +1,16 @@ >> +# To use the deprecated recipe check, a distribution should >> +# include this class in the INHERIT_DISTRO >> +# >> +# Features: >> +# >> +# * To add a package to the deprecated list, set: >> +# PNDEPRECATED[pn] = "message" >> +# >> + >> +addtask check_deprecated before do_fetch >> +python do_check_deprecated () { >> +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), >> False) >> + >> +if deprecated: >> +bb.warn("Recipe is deprecated: ", (deprecated)) >> +} >> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/ >> defaultsetup.conf >> index ca2f917..16ece3a 100644 >> --- a/meta/conf/distro/defaultsetup.conf >> +++ b/meta/conf/distro/defaultsetup.conf >> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', >> '/' + str(d.getVar('MACHINE' >> USER_CLASSES ?= "" >> PACKAGE_CLASSES ?= "package_ipk" >> INHERIT_BLACKLIST = "blacklist" >> +INHERIT_DEPRECATED = "deprecated" >> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool" >> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} >> ${INHERIT_BLACKLIST}" >> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} >> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}" >> -- >> 1.9.1 >> >> -- >> ___ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonaldwrote: > Based on the blacklist behaviour, recipes can be tagged as deprecated. > Such recipes will produce a warning message when included in a build but > unlike blacklisted recipes, the build will continue. Perhaps this should also be documented in manuals > > > Signed-off-by: Joe MacDonald > --- > > I threw this together a long time ago and never got around to sending it > out for > consideration, but after the excitement last week and this, I got thinking > about > it again and thought it might be useful. My specific use-case for this is > recipes I see in meta-networking that I know are largely abandonware but > that I > don't want to completely throw out without giving some kind of heads up. > Obviously this is purely informational, there's no mechanism set up for > purging > deprecated recipes, that's intended to be a maintainer activity, but the > idea > would be that the maintainer would flag a recipe as deprecated (probably > when > it's become more trouble than it seems to be worth) and thereafter users > would > have fair warning that this thing is on notice. If nobody speaks up > within some > amount of time the maintainer considers reasonable (I'm thinking a Yocto > release > cycle) then it's fair game to remove the recipe in question. > > meta/classes/deprecated.bbclass| 16 > meta/conf/distro/defaultsetup.conf | 3 ++- > 2 files changed, 18 insertions(+), 1 deletion(-) > create mode 100644 meta/classes/deprecated.bbclass > > diff --git a/meta/classes/deprecated.bbclass > b/meta/classes/deprecated.bbclass > new file mode 100644 > index 000..3dcdadb > --- /dev/null > +++ b/meta/classes/deprecated.bbclass > @@ -0,0 +1,16 @@ > +# To use the deprecated recipe check, a distribution should > +# include this class in the INHERIT_DISTRO > +# > +# Features: > +# > +# * To add a package to the deprecated list, set: > +# PNDEPRECATED[pn] = "message" > +# > + > +addtask check_deprecated before do_fetch > +python do_check_deprecated () { > +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False) > + > +if deprecated: > +bb.warn("Recipe is deprecated: ", (deprecated)) > +} > diff --git a/meta/conf/distro/defaultsetup.conf > b/meta/conf/distro/defaultsetup.conf > index ca2f917..16ece3a 100644 > --- a/meta/conf/distro/defaultsetup.conf > +++ b/meta/conf/distro/defaultsetup.conf > @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' > + str(d.getVar('MACHINE' > USER_CLASSES ?= "" > PACKAGE_CLASSES ?= "package_ipk" > INHERIT_BLACKLIST = "blacklist" > +INHERIT_DEPRECATED = "deprecated" > INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool" > -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} > ${INHERIT_BLACKLIST}" > +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} > ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}" > -- > 1.9.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes
Based on the blacklist behaviour, recipes can be tagged as deprecated. Such recipes will produce a warning message when included in a build but unlike blacklisted recipes, the build will continue. Signed-off-by: Joe MacDonald--- I threw this together a long time ago and never got around to sending it out for consideration, but after the excitement last week and this, I got thinking about it again and thought it might be useful. My specific use-case for this is recipes I see in meta-networking that I know are largely abandonware but that I don't want to completely throw out without giving some kind of heads up. Obviously this is purely informational, there's no mechanism set up for purging deprecated recipes, that's intended to be a maintainer activity, but the idea would be that the maintainer would flag a recipe as deprecated (probably when it's become more trouble than it seems to be worth) and thereafter users would have fair warning that this thing is on notice. If nobody speaks up within some amount of time the maintainer considers reasonable (I'm thinking a Yocto release cycle) then it's fair game to remove the recipe in question. meta/classes/deprecated.bbclass| 16 meta/conf/distro/defaultsetup.conf | 3 ++- 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 meta/classes/deprecated.bbclass diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass new file mode 100644 index 000..3dcdadb --- /dev/null +++ b/meta/classes/deprecated.bbclass @@ -0,0 +1,16 @@ +# To use the deprecated recipe check, a distribution should +# include this class in the INHERIT_DISTRO +# +# Features: +# +# * To add a package to the deprecated list, set: +# PNDEPRECATED[pn] = "message" +# + +addtask check_deprecated before do_fetch +python do_check_deprecated () { +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False) + +if deprecated: +bb.warn("Recipe is deprecated: ", (deprecated)) +} diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/defaultsetup.conf index ca2f917..16ece3a 100644 --- a/meta/conf/distro/defaultsetup.conf +++ b/meta/conf/distro/defaultsetup.conf @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + str(d.getVar('MACHINE' USER_CLASSES ?= "" PACKAGE_CLASSES ?= "package_ipk" INHERIT_BLACKLIST = "blacklist" +INHERIT_DEPRECATED = "deprecated" INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool" -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}" +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}" -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core