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

Fri Feb 24 20:51:46 UTC 2017

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 Balister <philip at 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.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/ab30cf20/attachment-0002.html>