| 1 |
Am Freitag, 1. September 2006 19:37 schrieb Brian Harring: |
| 2 |
> > > |
| 3 |
> > > old new |
| 4 |
> > > ----- ------ |
| 5 |
> > > foo.eclass new-foo.eclass |
| 6 |
> > |
| 7 |
> > We don't need a new file for that IMHO. I'd propose to add |
| 8 |
> > something like |
| 9 |
> > |
| 10 |
> > ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo" |
| 11 |
> > ECLASS_REPLACEMENTS="${ECLASS_REPLACEMENT} new-foo" |
| 12 |
> > |
| 13 |
> > to foo.eclass. In my eyes this is much less work as repoman merely |
| 14 |
> > has to check for 2 envvars. |
| 15 |
> |
| 16 |
> As much as I'm a fan of embedding the metadata into the object |
| 17 |
> itself, this sucks; reliant on either |
| 18 |
> |
| 19 |
> 1) grepping it out of the file (which means there is the potential |
| 20 |
> for rare false positives to occur). |
| 21 |
Correct, i don't like to grep for it. |
| 22 |
> |
| 23 |
> 2) bastardizing inherit to grab it, thus forcing a sourcing for every |
| 24 |
> single ebuild regardless of staleness |
| 25 |
Exactly. |
| 26 |
|
| 27 |
> Your example above seems to indicate preferring #2, which folks will |
| 28 |
> probably tell you to get stuffed on, forcing a regen of the packages |
| 29 |
> they're examining they won't like (will slow repoman down even |
| 30 |
> further). |
| 31 |
Well, one has to decide between functionality and speed at times. I |
| 32 |
think it's better to have the ebuild sourced on every run instead of |
| 33 |
sourcing it only when it cache is stale. |
| 34 |
|
| 35 |
> Also, the new-foo renaming can't be reversed cleanly; consider if the |
| 36 |
> old class was kernel-mod, new class is kernels, how do you know where |
| 37 |
> to split old/new? You can search ECLASS_DEPRECATED, but potential |
| 38 |
> for collision there makes it a crappy option, in the previous example |
| 39 |
> consider if kernel-mode and kernel were two deprecated eclasses, it |
| 40 |
> would falsely label the new class as mod-kernels. |
| 41 |
ECLASS_DEPRECATED="${ECLASS_DEPRECATED} foo:new-foo,new-foo-modules" |
| 42 |
|
| 43 |
> Meanwhile; I'd just stick a file up somewhere on gentoo.org, and |
| 44 |
> mangle repoman to pull down a copy every N days as needed and have it |
| 45 |
> use that; code can be reused from metadata.dtd usage. |
| 46 |
I like this option better than sticking another file into the public |
| 47 |
tree that no user will ever need. |
| 48 |
|
| 49 |
Danny |
| 50 |
-- |
| 51 |
Danny van Dyk <kugelfang@g.o> |
| 52 |
Gentoo/AMD64 Project, Gentoo Scientific Project |
| 53 |
-- |
| 54 |
gentoo-dev@g.o mailing list |
Archives