* Re: [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds
2005-03-17 2:09 ` W.Kenworthy
@ 2005-03-17 13:08 ` foser
2005-03-17 19:05 ` Dan Armak
1 sibling, 0 replies; 4+ messages in thread
From: foser @ 2005-03-17 13:08 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]
On Thu, 2005-03-17 at 10:09 +0800, W.Kenworthy wrote:
> I am not a dev, only a user, but who uses this stuff daily - and I can
> see big problems on the horizon with this for the average user on less
> than the fastest and latest hardware. I mainly use gnome (but have kde
> installed), and can attest to the fact that their multi package approach
> sucks. You get updates that fail and block other packages and you end
> up with a mixed package and broken gnome (has happened numerous times) -
> on gnome systems I keep a fluxbox (and a kde on my main desktop) install
> so I dont get caught with an unusable system. Then there is the fact
> that updates to gentoo stable usually mean multiple gnome packages
> updated - rarely is it just one or two packages. Gnome has only a
> fraction of the packages in kde, but the disadvantages of this from a
> user point of view are quite plain from experience.
If you stay plain stable arch and don't switch to ~arch or back you
should not ever have any problems with gnome. gnome is fine as long as
you upgrade only.
But the general concerns regarding large chuncks of ebuilds &
interdependencies with the lack of 100% dependency control in portage
(which gives rise to most gnome's problems) were also the things we told
the KDE team. We did warn them about it, a lot. Gnome was designed to be
a lot of small chunks from source, KDE just isn't. But it is their
choice, maybe it works, maybe they'll find out it's a hell anyway in
practice (updating 300 ebuilds with such a small team to begin with,
SLOTing, up/downgrading, etc.).
- foser
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds
2005-03-17 2:09 ` W.Kenworthy
2005-03-17 13:08 ` foser
@ 2005-03-17 19:05 ` Dan Armak
1 sibling, 0 replies; 4+ messages in thread
From: Dan Armak @ 2005-03-17 19:05 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 3608 bytes --]
On Thursday 17 March 2005 04:09, W.Kenworthy wrote:
> One thing missing from this how to avoid using the spit ebuilds (i.e.,
> some kind of use flag may be needed?).
'avoid'? You can still get the monolithic ebuilds if you emerge kde rather
than emerge kde-meta (and kdebase rather than kdebase-meta), etc.
> Even with distcc and multiple
> helpers, it only takes a few separate packages to blow the time needed
> to compile past a single package.
Are you saying it takes longer to compile just a few split packages derived
from kdebase than the monolithic kdebase package? Could you give actual
numbers to back that up?
It's true that distcc gives an advantage to the monolithic ebuilds because
they get to parallelize a lot more. But the solution to this should be
parallel emerging and sharing compiled packages, not huge packages.
>
> Example on a K6-500, kdelibs took (according to genlop) 11hrs 39 mins.
kdelibs is the same whether you use monolithic or split ebuilds.
> This was out of some 3 and a bit days compiling 86 packages (big update
> - mostly gnome related - see last paragraph). You say in the documents
> that a split kde will do around 100 packages in a typical update.
I don't know if that's typical... Anyway, monolithic ebuilds install the
equivalent of 300 packages every time. Even today's split ebuilds, which are
not optimal, take a lot less time to do an upgrade (with 100 changed
packages) than a monolithic ebuilds upgrade (recompiling everything).
> On
> the above figures, that looks like it will blow my compile times way
> out! Not just an acceptable small amount.
The time required to emerge kdelibs is far far bigger than any other kde split
package, and all but a few monolithic ones.
> Is it only me that thinks this idea is crazy, as the biggest single
> criticism of gentoo is build from source compile time, especially on the
> first install where this will hit really really badly? Monolithic
> builds are not ideal and have problems of their own, but here I think
> practicality needs to come into it.
You talk as if splitting kdebase into 40 ebuilds makes the total kdebase-meta
compile time 40 times greater than that of kdebase...
The very worst-case is several tens of percents more time. This is bad, but
it's not hopeless, and we'll be improving it in various ways.
> Alternatively, some major fixes to
> the build system to fix the core problem (mostly the configure stage
> needs caching properly) well before this is implemented.
This is true. It's why we still provide and support the monolithic ebuilds.
KDE4 will (probably? hopefully?) use SCons instead of autotools, which will be
1) a lot faster and 2) easily and powerfully cacheable (confcache for
autoconf configure scripts is a hack...). Even if they don't, there's
confcache, and unsermake, and we can avoid running make -f
admin/Makefile.common with some work. And other speedups like gcc 4 (faster
c++ frontend, precompiled headers...) coming up in the same timeframe.
As I've said elsewhere, our goal is that for kde 4 at the latest the split
ebuilds will be 1) almost as fast as the monolithic ones _then_ and 2) faster
than the monolithic ones are _now_. That accomplished, we'll drop the
monolithic ebuilds.
Remember that the split ebuilds provide a lot of benefits, they're not just a
gimmick.
--
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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread