J.O. Aho wrote:

>> Yes, but the last time I tried it on a really slow machine, a full
>> KDE upgrade took approximately 50% longer than usual because of all
>> the extra unpacking and configuring
>
> I agree on that it takes longer time with the initial install of
> kde-meta, but upgrades do take a lot shorter time, even if the
> dependency is more complex (by the way portage suxx when it comes to
> dependency checks).

Upgrades are not shorter in the long run, because KDE version upgrades
take *much* longer with split ebuilds. Just checked my logs, and even
on my fast machine the kdepim package takes a full hour longer to
compile with the split ebuilds (that's almost 70% additional compile
time). There would have to be a *lot* of minor individual package
upgrades in the span of a KDE version (which in my experience is around
3-4 months tops) in order for the split ebuilds to be faster.

>> (and full KDE upgrades aren't exactly rare).
>
> I a way this is a problem how Gentoo has decided to install, it must
> be quite wonderful for the devel working with the KDE packages in
> Gentoo that they can have 10 different versions installed at the same
> time, bu I doubt any normal user has two different versions of KDE
> installed for more than a hour. There are many times a minor update
> had been enough, if only one version would have been placed in the
> same place.

I don't really see how that relates to the problems of split vs
monolithic ebuilds. However, there have been times where it has been a
benefit for me to be able to have multiple KDE versions installed
simultaneously.

>> Not to mention that every single deep upgrade takes significantly
>> longer to calculate because of the more complex dependency tree.
>
> This is kind of marginal difference, you already have so much junk
> installed that you hardly can blame KDE-meta for this, just take a
> look at the bloated Gnome2 that so many Gentoo users has installed.

I've never used Gnome, but I can tell you that KDE-meta literally
doubled the number of installed packages on one of my machines, and
added 40% to another. That's something you can feel when waiting for
portage to churn through them. It's not a long wait, no, but it's
annoying because it's short enough that you can't really go do something
else, yet long enough to frustrate you in the end.

>> You just have to sit there and wait for portage to churn through it
>> all, every time. For a slow machine I would actually much prefer the
>> old monolithic ebuilds.
>
> There are many things that could make things a lot better for a slow
> machine, a well working portage instead of the python engined file
> collection.

I fail to see why people keep naming python as the reason why portage is
slow. If that was the case, then why is esearch so fast? No, it's a
deeper problem with the design of portage, but at this time there isn't
really a good alternative. Work is being done, however.

--
PeKaJe

Yeah, but they are good at making toys. I mean look at Windows...
-- From a Slashdot.org post about Microsoft's X-Box console