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
pgpENAvZOJ9aJ.pgp
Description: PGP signature
