On Tuesday 28 February 2006 15:10, Jakub Moc wrote: > 28.2.2006, 20:59:42, Mike Frysinger wrote: > > On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: > >> On Tue, Feb 28, 2006 at 05:11:57PM +0000, Ciaran McCreesh wrote: > >> > And it sticks out a nasty ewarn and says that the ebuild is probably > >> > broken. > >> > >> Which it _probably_ is. See, this is a numbers game. In most cases, if > >> you use the webapp eclass, setting SLOT="0" is incorrect. There are some > >> cases in which it's just fine. Until FEATURES="mindreader" is > >> implemented, how is the eclass to know what you're trying to do? So it > >> prints a warning and doesn't die. Number of angry users storming > >> bugs.g.o - 0. > > > > why do you need to be a mindreader ? the user requested they control the > > package, thus it isnt a bug, so dont issue a warning > > Sure, and when *ebuild* requested it instead, then portage will be > automagically informed. So yeah, we can implement yet another variable into > the eclass, and we can do tons of other magic voodoo about three lines of > eclass that noone has ever noticed until today, and the whole thing can be > a lot more complex for sure. Sorry, I call this a complete waste of time.
whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap -mike -- gentoo-dev@gentoo.org mailing list
