Here is the same script, more human readable and configurable:
P=kdebase-meta
V=3.4.0_beta1
for i in $(cat /usr/portage/kde-base/$P/$P-$V.ebuild | grep -o
"kde-base.*)" | sed 's/)//')
do
sed -i 's/~mips/mips/' /usr/portage/$i/`basename $i`-$V.ebuild
done
Enjoy,
Roman
On Mon, 17 Jan 2005 01:38:44 +0000, Roman Gaufman <[EMAIL PROTECTED]> wrote:
> 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
