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?
Adding some 15mb of ebuilds to portage just for one desktop environment isn't bloat? Particularly when the ebuilds already support splitting themselves in a different way via an environment variable?
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? Or, have you figured out a way to get around that? Besides, let's just say that normally everything would build in 48 hours (pretty optimistic...more realistically we're talking 72 hours). If it is 10% slower, we're talking about adding 4.8 to 7.2 hours more of emerge time (and I think only 10% slower is pretty optimistic on mips). Now this may seem trivial in the face of how long it would take to emerge normally, but if you consider what else you could be compiling during that wasted time, it is significant.
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?
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.
I don't think this is necessarily the case, more below...
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.
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. 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.
In any case, my general feeling is that nobody was considered except x86 and amd64 when this was decided upon. It is easy to take the speed of more recent machines for granted when coming up with ideas like this. I am also aware it is a choice our users make to use a compile-from-source distro on slow machines, but that's not an excuse for making things take longer for them.
Steve
-- [email protected] mailing list
