[gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds

[gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Hello,

I'm unmasking the KDE 3.4.0 ebuilds now, and wanted to remind anyone who 
missed this fact that starting with this release, we're providing split 
ebuilds. That means you can 'emerge konqueror kmail' rather than 'emerge 
kdebase kdepim'. Details and FAQ at 
http://www.gentoo.org/doc/en/kde-split-ebuilds.xml. 

-- 
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 --]

Re: [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds

[W.Kenworthy]

One thing missing from this how to avoid using the spit ebuilds (i.e.,
some kind of use flag may be needed?).  Even with distcc and multiple
helpers, it only takes a few separate packages to blow the time needed
to compile past a single package.

Example on a K6-500, kdelibs took (according to genlop) 11hrs 39 mins.
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.  On
the above figures, that looks like it will blow my compile times way
out!  Not just an acceptable small amount.

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.  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.

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.


BillK

*I did see the discussions on this previously and the MIPS peoples
objection to it, but from my own figures and experience, I dont want to
go the split ebuild path on any of my x86 systems, only one of which
could be called "fast".  By the time confcache comes out I may have
nearly finished compiling the first split ebuilds.

On Wed, 2005-03-16 at 22:16 +0200, Dan Armak wrote:
> Hello,
> 
> I'm unmasking the KDE 3.4.0 ebuilds now, and wanted to remind anyone who 
> missed this fact that starting with this release, we're providing split 
> ebuilds. That means you can 'emerge konqueror kmail' rather than 'emerge 
> kdebase kdepim'. Details and FAQ at 
> http://www.gentoo.org/doc/en/kde-split-ebuilds.xml. 
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds

[foser]

[-- 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 --]

Re: [gentoo-dev] KDE 3.4.0; reminder - there are split ebuilds

[Dan Armak]

[-- 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 --]