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 <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
