On Monday 17 January 2005 00:55, Stephen P. Becker wrote: > You just can't expect some of these > non-x86 arches that have smaller dev teams to have the time to mess with > 400+ ebuilds for kde. �Also, emerging 400+ ebuilds on many of the > machines we support is just not feasable. �Not only that, but the bloat > this brings to the portage tree is awful. � This part I don't understand. Why is it bloat?
> I just hope this doesn't go > further in the future to where the ebuilds get spread across the tree > into separate categories. I'm against distributing them over multiple categories, too. --- I've read all the posts below the one I'm replying to, and this is my summarized reply. First of all, we'll have monolithic ebuilds supported equally with split ones all the way through KDE 3.4 (KDE 4 being at least a year away IIRC). So we're not talking about dropping KDE support on mips tomorrow morning. We'll have plenty of time to work out a solution. And if we fail to, the kde team might (haven't discussed yet) agree to go on supporting monolithic ebuilds indefinitely to allow kde to be used on small/slow archs. Either that, or someone will get really angry and come up with some totally new speedup :-) (Maybe Gentoo'll switch to subversion :-) Go on supporting the monolithic ebuilds for now, and hopefully around KDE 4.0 things will look better (confcache, unsermake, new gcc features, qt4 ...). emerge kde-meta may always be 5 or 10 percent slower than emerge kde, but emerge kde-meta a year from now should be faster than emerge kde is today. confcache, BTW, is (so I am told) alreay in the development version of portage, slated for release in half a year. As for the other issues raised in this thread: About the repoman/keywording time issue: you can run repoman in the kde-base category rather than per-package. My 9 minutes measurement (>50% of which was I/O, FWIW) was on an Athlon 2600+. I don't know what that means for a mips box :-/ If a big keywording commit is the only issue, there are ways around it, because it only happens once every few weeks and is coordinated between the mips team members anyway. You can do it from a faster non-mips box you have around, or ask someone from the kde team to do it from a fast x86 box. It's not as pretty as just doing it yourselves, but it's not IMHO a complete blocker to the adoption of split ebuilds. About the compilation time: it's considerably higher than the monolithic ebuilds', true; confcache should eliminate most of the overhead. Consider, however, that for a bugfix release only some of the packages change. Using monolithic packages, you had to re-compile and test and keyword all of KDE 3.3.2, but actually less than 100 packages out of 325 had changed. With split ebuilds, packages that don't change simply don't get new ebuild versions, even though upstream relabels them. I guess expected you to be happier about the split ebuilds. I expect most mips users don't want to emerge or run all of KDE in any case. A couple of new ideas to close with: maybe it'd make sense for you to keyword and support a reduced set of packages? Some of them aren't relevant on mips anyway. In the same way, you could keyword packages gradually over the weeks following a minor release (3.4 is 'minor', although it's pretty big). Nothing says you have to test and keyword all the 350 packages in one go, you could start with a working minimal system of say 30 or 40 core packages and expand gradually from that. -- Dan Armak Gentoo Linux developer (KDE) Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951
pgpfBa6CpPldA.pgp
Description: PGP signature
