On Sun, 16 Jan 2005 20:09:34 -0500, Kumba <[EMAIL PROTECTED]> wrote: > Roman Gaufman wrote: > > > > 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.
Considered, and I still dont see how that applies to kde vs kde-meta. ./configure will be cached by the time the monolithic packages are removed, but other than that temporary problem, those points are redundant and apply to kde as much as kde-meta. > > 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." Bah! for i in $(cat kdebase-meta-3.4.0_beta1.ebuild | grep -o "kde-base.*)" | sed 's/)//'); do sed -i 's/~mips/mips/' /usr/portage/$i/$i-3.4.0_beta1.ebuild ; done There, a simple 1 liner I wrote in 10 seconds to properly keyword all packages owned by kdebase. Where is the problem? You are testing the *same* 15 packages, i.e. emerge kdemultimedia-meta. -- Only difference is you are given the option to save hours by not compiling things you dont want to test. Feel free not to use that option though. Is this so hard to grasp? > > --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 > -- [email protected] mailing list
