How is it different to emerge kde and report bugs? If the mics team doesnt do that they they dont support the monolithic ebuilds either.
1) The mips team comprises about ~4-5 active devs, with ~3-4 more devs on the side that contribute when they have the time to spare.
2) Of said active devs, maybe ~1-3 are able to test X-related material. X is a pretty big field, and has a lot of packages, apps, DE's, WM's, etc..
3) Mips machines are not the fastest boxes on the block. That, and X support varies from box to box, and from video board to video board. Not all available boards for SGI systems work under Linux, primarily due to lack of hardware documentation.
4) Emerging KDE takes time. A LONG time on mips. If you think compiling KDE on an x86 box takes a decent amount of time, then you will be wholly unprepared for the wait on a mips box.
5) Lastly, x86 != mips, therefore there is the possibility of unique bugs to appear on mips that will not appear on x86, and vice-a-versa. This is already the case with some things like C++ and Java on mips (one works, the other doesn't). Mips also has 3 ABIs, x86 has one. While we only support 1 ABI as stable, the future has the possibility of supporting all three (maybe two). Mips also isn't limited to just SGI systems -- there's a whole new world beyond the SGI equipment, and we haven't even begun to test on that hardware.
//---
Consider all these factors, and then try re-evaluating your comment. If you think hard enough, you may be able to grasp the level of difficulty some of us non-x86 arch teams have to deal with.
I dont mean to be rude, but you're missing the point. All the meta packages do is do what the monolithic packages do. Call ./configure && make && make install. Only in individual folders. No matter how you look at it, you still create a patch against kdebase or kdemultimedia, etc. The rest is just running a simple script to change the KEYWORDS line on the packages owned by the meta package (i.e. kdebase-meta). It doesnt make any difference on arch team's end.
You still miss the point here that instead of testing and keyword ~15 packages/ebuilds, we now have to test & keyword ~350 ebuilds. Take into account my above response about your first comment, and then consider the number of ebuilds we'd have to check deps on and ensure are keyworded appropriately, this makes the task of us (and other non-x86 arch teams) exponentially more cumbersome.
Finally, to sum everything up into one sentence: "There is no spoon."
--Kumba
--
"Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond
-- gentoo-dev@gentoo.org mailing list
