On Monday 17 January 2005 17:18, Stephen P. Becker wrote: > Adding some 15mb of ebuilds to portage just for one desktop environment > isn't bloat? Any 350 ebuilds would take that much. Nothing I can do about it. Most of them don't even have function defs thanks to eclasses, so they can't become any smaller.
> Particularly when the ebuilds already support splitting > themselves in a different way via an environment variable? They DO NOT support any such thing. The split ebuilds were made so that people wouldn't have to use the horrible DO_NOT_COMPILE. It's at least halfway to installing manually from source. > > > 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. > > Is that taking into account unpacking the source tarball for each > individual ebuild? Yes, that's what causes my 10 percent estimate. > Or, have you figured out a way to get around that? Well, we only extract the necessary files from the tarballs each time. Of course we could break up every KDE tarball on release and distribute lots of small tarballs on mirror://gentoo. I don't particularly mind if the extra mirror load isn't a problem and if it will help you. There'll always be some overhead, but not too much I think. Suppose an average of 0.5MB .tar.bz2 with 100 files per package (to take filesystem costs into account), with 350 packages total - how much would all the unpacking (and deleting each package workdir) take on an average mips? (I estimate these numbers are all somewhat higher than the real averages.) > > 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. > > It isn't a blocker, but more of an annoyance. Why make something more > complex when it doesn't have to be? Maybe it didn't _have_ to be, but on x86 it's well worth it due to new features. So yeah, it's a tradeoff. > I happen to know we have several users will a *full* kde install, so we > do have people using it. However, a minimal system of 30 to 40 core > packages isn't KDE. It is some small collection of programs that are > part of the upstream KDE packages. You don't really get the true KDE > experience as was intended. I didn't mean that you should stop at 40 core packages. I meant you should start with that and add all the rest over two or three weeks (for bugfix upgrades it'd take a lot less time, of course). > Besides, we would almost have to maintain > our own meta-ebuild for *just* those packages that we have tested and > keyworded on mips. Otherwise, our users would have to pick their way > through, trying to figure out what they can and can't install. Either > that, or we would have to totally screw up the kde-meta ebuilds with a > bunch of "use mips || foo" type lines to satisfy repoman, and that kind > of solution is ugly. We already have to do this a couple times in the > gnome meta-ebuild (admittedly for programs that simply don't work on our > arch), and I hate that. I would be more inclined just to tell our users > to unmask the packages they want to use to get their own custom kde > install going. OK, so it wasn't a good idea. > > In any case, my general feeling is that nobody was considered except x86 > and amd64 when this was decided upon. The goal we considered is simple: to make the speed penalty negligible, even to mips people. However, the only thing that directly reduces the split ebuilds' overhead is confcache (and the small benefit of splitting up the tarballs). Oh yeah, and the replacement of some ebuilds which don't compile anything (like iconthemes) with lightweight ebuilds installing statis trees. Everything else would speed up the monolithic ebuilds almost as much: unsermake, enable-final, new gcc goodies... So as I said, split ebuilds will always be slower than monolithic ones. The question is whether split ebuilds that are fast enough in the absolute sense would satisfy you. How slow, or fast, are today's 3.3.x monolithic ebuilds to your taste? BTW, what kind of RAM size do mips boxes have? If by any chance it's large compared to their CPU power - if we consider x86 the norm - then this is a good moment to mention I wanted to try using enable-final again :-) But if not, we'll just disable it on your arch. -- 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
pgpNpL1XfIdm2.pgp
Description: PGP signature
