On Tuesday 28 February 2006 16:02, Jakub Moc wrote: > 28.2.2006, 21:39:43, Mike Frysinger wrote: > > 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 > > Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, > eclass inherited illegally crap and a couple of others - this isn't going > anywhere.
unrelated ... that is a portage limitation that has deeper work going on around it to resolve the issue properly ... this is an eclass limitation that can be resolved now > You are trying to solve something that noone ever complained about. Why not > rather solve stuff like ebuilds that depend unconditionally on arts, but > because they inherit kde eclass they get bogus arts use flag from the > eclass. This is an issue that's truly confusing and that people are filing > bugs about. There's the difference between doing something useful and > wasting time on an artificially invented issue. right, so from now on people shouldnt bother fixing issues until a bug is filed, that way we know someone actually cares enough to have the issue resolved today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org -mike -- gentoo-dev@gentoo.org mailing list