<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 24, 2017 at 9:39 PM, Philip Balister <span dir="ltr"><<a href="mailto:philip@balister.org" target="_blank">philip@balister.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/24/2017 01:16 AM, Martin Jansa wrote:<br>
>> If nobody speaks up within some<br>
> amount of time the maintainer considers reasonable (I'm thinking a Yocto<br>
> release<br>
> cycle) then it's fair game to remove the recipe in question.<br>
><br>
> Maybe this is different case with at least some PNBLACKLIST entries we<br>
> currently have, but<br>
> I don't remove PNBLACKLISTed recipes, because as we discussed it's always<br>
> easier to unblacklist<br>
> recipe from e.g. DISTRO config if the issue doesn't affect you for whatever<br>
> reason and causes<br>
> less churn in the metadata when it gets unblacklisted.<br>
><br>
> And many PNBLACKLISTed recipes are also abandonware.<br>
><br>
<br>
</span>I think we need to use a different "flag" for recipes that need<br>
updating, and have maintained upstreams from recipes that have upstreams<br>
that are abandoned.<br>
<br>
So blacklist broken recipes with good upstreams and deprecate recipes<br>
with dead upstreams.<br>
<span class="HOEnZb"><font color="#888888"><br>
Philip<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> So my question is, if we will remove PNDEPRECATed recipes after one cycle,<br>
> should we start<br>
> removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both<br>
> cases it might backfire<br>
> when someone will fail to find recipe for his favorite abandonware and will<br>
> try to add completely<br>
> new recipe for it, or we see someone restoring these recipes (e.g. in own<br>
> layers instead of fixing<br>
> the PNBLACKLIST/PNDEPRECATED reasons in original layer).<br>
><br>
> On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br>
><br>
>><br>
>> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald <<a href="mailto:joe_macdonald@mentor.com">joe_macdonald@mentor.com</a>><br>
>> wrote:<br>
>><br>
>>> Based on the blacklist behaviour, recipes can be tagged as deprecated.<br>
>>> Such recipes will produce a warning message when included in a build but<br>
>>> unlike blacklisted recipes, the build will continue.<br>
>><br>
>><br>
>> Perhaps this should also be documented in manuals<br>
>><br>
>>><br>
>>><br>
>>> Signed-off-by: Joe MacDonald <<a href="mailto:joe_macdonald@mentor.com">joe_macdonald@mentor.com</a>><br>
>>> ---<br>
>>><br>
>>> I threw this together a long time ago and never got around to sending it<br>
>>> out for<br>
>>> consideration, but after the excitement last week and this, I got<br>
>>> thinking about<br>
>>> it again and thought it might be useful. My specific use-case for this is<br>
>>> recipes I see in meta-networking that I know are largely abandonware but<br>
>>> that I<br>
>>> don't want to completely throw out without giving some kind of heads up.<br>
>>> Obviously this is purely informational, there's no mechanism set up for<br>
>>> purging<br>
>>> deprecated recipes, that's intended to be a maintainer activity, but the<br>
>>> idea<br>
>>> would be that the maintainer would flag a recipe as deprecated (probably<br>
>>> when<br>
>>> it's become more trouble than it seems to be worth) and thereafter users<br>
>>> would<br>
>>> have fair warning that this thing is on notice. If nobody speaks up<br>
>>> within some<br>
>>> amount of time the maintainer considers reasonable (I'm thinking a Yocto<br>
>>> release<br>
>>> cycle) then it's fair game to remove the recipe in question.<br>
>>><br>
>>> meta/classes/deprecated.<wbr>bbclass | 16 ++++++++++++++++<br>
>>> meta/conf/distro/defaultsetup.<wbr>conf | 3 ++-<br>
>>> 2 files changed, 18 insertions(+), 1 deletion(-)<br>
>>> create mode 100644 meta/classes/deprecated.<wbr>bbclass<br>
>>><br>
>>> diff --git a/meta/classes/deprecated.<wbr>bbclass b/meta/classes/deprecated.<br>
>>> bbclass<br>
>>> new file mode 100644<br>
>>> index 0000000..3dcdadb<br>
>>> --- /dev/null<br>
>>> +++ b/meta/classes/deprecated.<wbr>bbclass<br>
>>> @@ -0,0 +1,16 @@<br>
>>> +# To use the deprecated recipe check, a distribution should<br>
>>> +# include this class in the INHERIT_DISTRO<br>
>>> +#<br>
>>> +# Features:<br>
>>> +#<br>
>>> +# * To add a package to the deprecated list, set:<br>
>>> +# PNDEPRECATED[pn] = "message"<br>
>>> +#<br>
>>> +<br>
>>> +addtask check_deprecated before do_fetch<br>
>>> +python do_check_deprecated () {<br>
>>> + deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),<br>
>>> False)<br>
>>> +<br>
>>> + if deprecated:<br>
>>> + bb.warn("Recipe is deprecated: ", (deprecated))<br>
>>> +}<br>
>>> diff --git a/meta/conf/distro/<wbr>defaultsetup.conf b/meta/conf/distro/<br>
>>> defaultsetup.conf<br>
>>> index ca2f917..16ece3a 100644<br>
>>> --- a/meta/conf/distro/<wbr>defaultsetup.conf<br>
>>> +++ b/meta/conf/distro/<wbr>defaultsetup.conf<br>
>>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${<wbr>TCLIBC}${@['',<br>
>>> '/' + str(d.getVar('MACHINE'<br>
>>> USER_CLASSES ?= ""<br>
>>> PACKAGE_CLASSES ?= "package_ipk"<br>
>>> INHERIT_BLACKLIST = "blacklist"<br>
>>> +INHERIT_DEPRECATED = "deprecated"<br>
>>> INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"<br>
>>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}<br>
>>> ${INHERIT_BLACKLIST}"<br>
>>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}<br>
>>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"<br>
>>> --<br>
>>> 1.9.1<br>
>>><br>
>>> --<br>
>>> ______________________________<wbr>_________________<br>
>>> Openembedded-core mailing list<br>
>>> <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
>>> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
>>><br>
>><br>
>> --<br>
>> ______________________________<wbr>_________________<br>
>> Openembedded-core mailing list<br>
>> <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
>> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
>><br>
>><br>
><br>
><br>
><br>
</div></div></blockquote></div><br></div>