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.
And that is my point. 350 ebuilds that do the same thing that 12 did before is bloat.
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.
Why is DO_NOT_COMPILE so horrible? With that, people had to track down which programs they didn't want and add them to that variable. With split ebuilds, people will have to track down which ebuilds they don't want, bypass the meta-ebuild that installs everything, and then either merge what they want one-by-one or maintain their own meta-ebuild.
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.
In which case, you have severely underestimated the slowdown on mips. Unpacking huge source tarballs is veeeeeeeeerrrry slow. Unpacking huge source tarballs 400 times is awful on an indy, which is the typical mips desktop machine. Just look at this, which is on a r5000, 150mhz indy with 160mb of RAM (pretty close to being a maxed out indy for most people's purposes):
pimpdaddy kdebase # time ebuild kdebase-3.3.2-r1.ebuild unpack
>>> md5 src_uri ;-) kdebase-3.3.2.tar.bz2
>>> Unpacking source...
>>> Unpacking kdebase-3.3.2.tar.bz2 to /var/tmp/portage/kdebase-3.3.2-r1/work
* Applying konsole-3.3.2.patch ... [ ok ]
* Applying post-3.3.2-kdebase-htmlframes2.patch ... [ ok ]
* Applying startkde-3.3.2-r1-gentoo.diff ... [ ok ]
>>> Source unpacked.
real 6m50.818s user 2m34.113s sys 0m50.345s
Now, multiply that by 40 for kdebase, or by 350 for the whole taco, and you can see why I'm concerned. I should say that this number is somewhat skewed because my distfiles are over nfs, but the network throughput is about 1mb/sec compared to 2mb/sec for the disk controller, so it's not *that* big of a difference.
I guess there isn't a way to come up with some sort of portage hackery whereby the portage tmpdir doesn't get cleaned out until the last of the split ebuilds is merged?
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.)
This would be better than unpacking the huge kde source tarballs every time, but then it would bloat the mirrors somewhat.
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.
We tell people not to bother with gentoo unless they have at least 128mb of RAM. Indys max out at 256mb, and some of the more powerful machines like O2 can have up to 1gb now (thanks to iluxa). Right now, an r5000 O2 is the most powerful machine that is capable of running X, but even that is still not that much faster than a maxed out Indy. Hopefully, we should have X support on machines like octane, which are far more powerful. Even then, they still aren't speed demons by today's peecee standards.
Steve
-- gentoo-dev@gentoo.org mailing list
