[OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

[Martin Jansa]

> 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 Raj <raj.khem at gmail.com> wrote:

>
> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald <joe_macdonald at 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_macdonald at 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 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 0000000..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 at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170224/ac45e679/attachment-0002.html>