[gentoo-dev] repoman: check for deprecated eclasses

[gentoo-dev] repoman: check for deprecated eclasses

[Stefan Schweizer]

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

-- 
gentoo-dev@gentoo.org mailing list

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

[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
-- 
gentoo-dev@gentoo.org mailing list

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

[Danny van Dyk]

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.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Danny van Dyk]

Am Freitag, 1. September 2006 19:37 schrieb Brian Harring:
> > >
> > > 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).
Correct, i don't like to grep for it.
>
> 2) bastardizing inherit to grab it, thus forcing a sourcing for every
> single ebuild regardless of staleness
Exactly.

> 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).
Well, one has to decide between functionality and speed at times. I 
think it's better to have the ebuild sourced on every run instead of 
sourcing it only when it cache is stale.

> 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.
ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo:new-foo,new-foo-modules"

> 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.
I like this option better than sticking another file into the public 
tree that no user will ever need.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 3646 bytes --]

On Sat, Sep 02, 2006 at 01:37:26AM +0200, Danny van Dyk wrote:
> Am Freitag, 1. September 2006 19:37 schrieb Brian Harring:
> > > >
> > > > 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).
> Correct, i don't like to grep for it.
> >
> > 2) bastardizing inherit to grab it, thus forcing a sourcing for every
> > single ebuild regardless of staleness
> Exactly.
> 
> > 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).
> Well, one has to decide between functionality and speed at times. I 
> think it's better to have the ebuild sourced on every run instead of 
> sourcing it only when it cache is stale.

Reasoning?  Forcing repoman to be slower sounds pretty damn dumb to me 
without a damn good reason to go with it (this doesn't qualify imo).

Additionally, for all implementations that will attempt to support 
this, it'll require bastardizing the cache regeneration to also pull 
out these two vars in select instances; adds some special casing into 
a codepath that must never screw up (thus should be kept as simple as 
possible).

Really doesn't strike me as a good idea, especially in light of the 
lifetime of these vars (see below).


> > 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.
> ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo:new-foo,new-foo-modules"
> 
> > 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.
>
> I like this option better than sticking another file into the public 
> tree that no user will ever need.

Instead, modifying the eclass metadata and adding two new keys, that 
users will never need is fine? :)

This isn't really user data, tiz developer data; thus the user bit 
doesn't matter.  Sarcasm aside, what *does* matter as that the 
purpose of this is a temporary hack to cover portages ass.

Have to mark eclasses as deprecated because eclasses cannot be 
removed; lose that restriction, no longer need to deprecate the 
eclass, just punt the sucker.

As such, plan for doing it right, thus the repoman addition should be 
easy reversible.  Mangling the entire cache generation codepath with a 
nasty hack that doesn't have a good reason to be forced that way, that 
further is _temporary_ doesn't strike me as wise.

Really, stick a list up somewhere easily accessible, write a check to 
scan for those eclasses.  Dirt simple, no reason to make this complex.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Daniel Ostrow]

<snip>

> > I like this option better than sticking another file into the public 
> > tree that no user will ever need.
> 
> Instead, modifying the eclass metadata and adding two new keys, that 
> users will never need is fine? :)
> 
> This isn't really user data, tiz developer data; thus the user bit 
> doesn't matter.  Sarcasm aside, what *does* matter as that the 
> purpose of this is a temporary hack to cover portages ass.
</snip>

In light of it being useless data for users is there any reason not to
add the files to CVS and then pull them out before the tree is synced
with the master mirror as part of that script?

--Dan

-- 
gentoo-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

On Fri, Sep 01, 2006 at 09:54:09PM -0700, Daniel Ostrow wrote:
> <snip>
> 
> > > I like this option better than sticking another file into the public 
> > > tree that no user will ever need.
> > 
> > Instead, modifying the eclass metadata and adding two new keys, that 
> > users will never need is fine? :)
> > 
> > This isn't really user data, tiz developer data; thus the user bit 
> > doesn't matter.  Sarcasm aside, what *does* matter as that the 
> > purpose of this is a temporary hack to cover portages ass.
> </snip>
> 
> In light of it being useless data for users is there any reason not to
> add the files to CVS and then pull them out before the tree is synced
> with the master mirror as part of that script?

Devs are lazy and don't always do a full cvs up, same reason the 
repoman metadata.xml check relies on pulling metadata.dtd down, 
instead of having a copy pushed into the cvs repository.

Re: yoinking the file from the cvs->rsync transfer, frankly who cares.  
It's one file out of 124 _thousand_ files; <400 bytes.  Really ain't 
worth it.

~brian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

The file listing the derecated overlays is fine. What about revdep-rebuild and 
emerge regarding installed stuff and overlays?


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

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

[Stefan Schweizer]

Carsten Lohrke wrote:
> What about revdep-rebuild and
> emerge regarding installed stuff and overlays?

what do you mean? Please elaborate

I have only repoman in mind for now.

- Stefan

-- 
gentoo-dev@gentoo.org mailing list

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

[Alec Warner]

Carsten Lohrke wrote:
> The file listing the derecated overlays is fine. What about revdep-rebuild and 
> emerge regarding installed stuff and overlays?
> 
> 
> Carsten

We are talking eclasses...not overlays...
-- 
gentoo-dev@gentoo.org mailing list