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 <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 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@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
