Jakub Moc wrote: > Alec Warner napsal(a): >> Jakub Moc wrote: >>> Danny van Dyk napsal(a): >>>> which breaks the metadata cache. Any objections to change it >>>> to >>>> >>>> SLOT=0 >>> As noted on the relevant bug [1], the eclass is a complete no-op and >>> nothing can be installed using this eclass (has been so for quite some >>> time). Fixing it doesn't make sense, making it dummy or even removing it >>> (plus the unusable single ebuild which inherits it) does. >>> >>> >>> [1] http://bugs.gentoo.org/show_bug.cgi?id=162960 >>> >> And we already told you, removing it isn't a good solution (even if it >> technically works within the bounds of the current api). The bug is >> that the SLOT invalidates cache entries and it's trivial to fix. > > The eclass is not trivial to fix, to be fixed, this eclass would require > a complete rewrite from scratch. There's no usable ebuild for this > eclass and the eclass is completely moot. Still fail to see what are you > trying to fix as opposed to removing a broken non-functional cruft from > the tree. > >
See the bug? It says 'slot is being set to $KV, which breaks the metadata cache. Also, portage may fail to set $KV to a valid slot value (typically 0) and thus the package may end up with SLOT="" which is also invalid'. Thats what we are trying to fix. The fact that the eclass sucks balls is irrelevant, I could say the same of a dozen other old as hell eclasses. But they remain in the tree, as will this one. -- gentoo-dev@gentoo.org mailing list
