Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] matrox.eclass
Date: Sun, 28 Jan 2007 10:18:35
Message-Id: 45BC7800.9070105@gentoo.org
In Reply to: Re: [gentoo-dev] matrox.eclass by Jakub Moc
1 Jakub Moc wrote:
2 > Alec Warner napsal(a):
3 >> Jakub Moc wrote:
4 >>> Danny van Dyk napsal(a):
5 >>>> which breaks the metadata cache. Any objections to change it
6 >>>> to
7 >>>>
8 >>>> SLOT=0
9 >>> As noted on the relevant bug [1], the eclass is a complete no-op and
10 >>> nothing can be installed using this eclass (has been so for quite some
11 >>> time). Fixing it doesn't make sense, making it dummy or even removing it
12 >>> (plus the unusable single ebuild which inherits it) does.
13 >>>
14 >>>
15 >>> [1] http://bugs.gentoo.org/show_bug.cgi?id=162960
16 >>>
17 >> And we already told you, removing it isn't a good solution (even if it
18 >> technically works within the bounds of the current api). The bug is
19 >> that the SLOT invalidates cache entries and it's trivial to fix.
20 >
21 > The eclass is not trivial to fix, to be fixed, this eclass would require
22 > a complete rewrite from scratch. There's no usable ebuild for this
23 > eclass and the eclass is completely moot. Still fail to see what are you
24 > trying to fix as opposed to removing a broken non-functional cruft from
25 > the tree.
26 >
27 >
28
29 See the bug? It says 'slot is being set to $KV, which breaks the
30 metadata cache. Also, portage may fail to set $KV to a valid slot value
31 (typically 0) and thus the package may end up with SLOT="" which is also
32 invalid'.
33
34 Thats what we are trying to fix.
35
36 The fact that the eclass sucks balls is irrelevant, I could say the same
37 of a dozen other old as hell eclasses. But they remain in the tree, as
38 will this one.
39 --
40 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] matrox.eclass Jakub Moc <jakub@g.o>