Re: [gentoo-dev] repoman: check for deprecated eclasses

[Brian Harring]

On Fri, Sep 01, 2006 at 06:57:22PM +0200, Danny van Dyk wrote:
> Am Freitag, 1. September 2006 17:05 schrieb Alec Warner:
> > Stefan Schweizer wrote:
> > > Hi,
> > >
> > > Repoman needs to check for deprecated eclasses, see
> > > http://bugs.gentoo.org/141677
> > >
> > > As a result of the discussion in the bug, we would like to add
> > > $PORTDIR/qa-data/eclass.deprecated
> > > to allow to deprecate eclasses properly and make repoman fail.
> > >
> > > This will allow us to avoid problems with new ebuilds for
> > > deprecated eclasses which result in bugs like
> > > Bug 141629 dev-util/systemtap-20060325.ebuild uses deprecated
> > > kernel-mod.eclass
> > > I believe the developer has not known anything about that
> > > kernel-mod is deprecated when making that ebuild. Now he ignores
> > > the bug and we have that old eclass used again :(
> > >
> > > Best regards,
> > > - Stefan
> >
> > I would prefer to see a patch for this first, and then modify
> > gentoo-x86 second; but I agree in principle.  What of the
> > conversation about 2 files, one for "this eclass is currently being
> > deprecated" -> repoman warning; and "this eclass is no longer usable"
> > -> repoman failure.
> >
> > Also the deprecated -> new-eclass mapping.  Afaik that didn't go so
> > well for me; but I still like it ;)
> >
> > old			new
> > -----			------
> > foo.eclass		new-foo.eclass
>
> We don't need a new file for that IMHO. I'd propose to add something
> like
>
> ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo"
> ECLASS_REPLACEMENTS="${ECLASS_REPLACEMENT} new-foo"
>
> to foo.eclass. In my eyes this is much less work as repoman merely has
> to check for 2 envvars.

As much as I'm a fan of embedding the metadata into the object itself, 
this sucks; reliant on either

1) grepping it out of the file (which means there is the potential for 
rare false positives to occur).

2) bastardizing inherit to grab it, thus forcing a sourcing for every 
single ebuild regardless of staleness

Your example above seems to indicate preferring #2, which folks will 
probably tell you to get stuffed on, forcing a regen of the packages 
they're examining they won't like (will slow repoman down even 
further).

Also, the new-foo renaming can't be reversed cleanly; consider if the 
old class was kernel-mod, new class is kernels, how do you know where 
to split old/new?  You can search ECLASS_DEPRECATED, but potential for 
collision there makes it a crappy option, in the previous example 
consider if kernel-mode and kernel were two deprecated eclasses, it 
would falsely label the new class as mod-kernels.

Meanwhile; I'd just stick a file up somewhere on gentoo.org, and 
mangle repoman to pull down a copy every N days as needed and have it 
use that; code can be reused from metadata.dtd usage.

~harring