What are the packages you HATE to emerge and WHY ?

Message

djdunn · Post by **djdunn** » Thu Dec 03, 2009 8:38 pm

darklegion wrote:
djdunn wrote:uh i hate stuff that takes more than 4 gigs to emerge cause it gets dumped into swap and my videogames slow way way down.

normally i can game while i compile.
You should probably lower make's job level (e.g MAKEOPTS=-j2) , this is probably why your compiles use so much memory.You don't have to lower it for all compiles, just for the ones that use a lot of memory.Using /etc/portage/env would probably be a good idea here.
Also, you might just be setting the job level too high, it should only be one level higher than the amount of cores in your system, which will be -j3 for a dual core and -j5 for a quad core.Alternatively you can use Con's Brainfuck Scheduler (BFS), which is optimized to use all of the cores efficiently.So you can use -j2 for a dual core, in that case.

I don't have a problem with things, I'm just saying things like openoffice or UT2004 things that are just huge like ut2004 unpacks the entire dvd like ~6gb into portage tmp before it installs it, and because i have a tmpfs mounted to portage tmp it takes up all my ram + swap

Cyker · Post by **Cyker** » Fri Dec 04, 2009 12:29 am

The good thing is that lessons were learned from expat; I have the warnings enabled (i.e. PORTAGE_ELOG_SYSTEM="save_summary echo"), and also the eselect news thing that'd been suggested and discussed for ages finally appeared and was ossom

I'm certain these warnings have helped save my system on a few occasions now; It's certainly better than having to boot up Windows to check the forums and find out what horrible things have broken that way!

As for my overlay mods, I considered submitting them, but I don't think they'd be welcome:
Unless things have changed significantly since I last looked, there is a definite trend towards fewer USEflags, whereas I tend to USEflag every single optional feature the ./configure script offers...!
I also optionalize as many dependencies as possible;The net result of all this is some of my ebuilds have double or triple the number of USEflags of the original ebuilds, but have far fewer hard dependencies.
The other thing is a lot of the things in my overlay are me restoring USE flag options that were removed due to some asinine bug report about something not working or being buggy, so I'd doubt that'd get reversed...
I do find it quite vexing but try not to complain too much as the maintainers are probably under a lot more pressure than me to keep some semblance of stability without being worked to death (It can be quite time consuming maintaining it, despite the relatively small size!)

d2_racing · Post by **d2_racing** » Fri Dec 04, 2009 1:54 am

Now I remember the famous Expat hell

codestation · Post by **codestation** » Fri Dec 04, 2009 6:18 am

I hate compiling Openoffice, boost, glibc, gcc, xulrunner (those takes too long), 2 webkits (chromium and qt, at least i got rid of webkit-gtk), amarok (i forgot how many times i compiled that thing in the past month while trying to find a bug), KDE (a couple of days ago i had compiled almost all of 4.3.3, then 4.3.4 appears wtf

) and QT.

P.D.: God, dont remind me of patch-2.6, i had to recompile almost a month worth of packages

P.D.2.: I am glad that the expat hell dont got me, but i cant say the same about the libstdc++.so.5 bug of some years ago that broke almost all my OS.

Dr.Willy · Post by **Dr.Willy** » Fri Dec 04, 2009 8:13 pm

Cyker wrote:I also optionalize as many dependencies as possible;The net result of all this is some of my ebuilds have double or triple the number of USEflags of the original ebuilds, but have far fewer hard dependencies.

Well, if you happen to have a chromium ebuild that doesn't depend on gconf and gnome-icon-theme (wtf), let me know.

Cyker · Post by **Cyker** » Sat Dec 05, 2009 10:57 am

Sorry, not a big fan of Chromium, but it's quite easy if you want to have a go your self!

Cyker's Quick and Dirty Guid to ebuild hacking!
1) Open /etc/make.conf in your fav. text editor (I use mcedit)
2) Stick

Code: Select all

PORTDIR_OVERLAY="/usr/local/portage"

in it somewhere
3) mkdir -p /usr/local/portage/www-client/chromium/files
4) cp /usr/portage/www-client/chromium/* /usr/local/portage/www-client/chromium/
5) cp /usr/portage/www-client/chromium/files/* /usr/local/portage/www-client/chromium/files/
6) cd /usr/local/portage/www-client/chromium
7) Fire up your editor with the ebuild version of chromium you want to screw around with (e.g.

Code: Select all

mcedit chromium-4.0.260.0.ebuild

)
8 ) Remove those dependencies!
9) Exit, run

Code: Select all

ebuild chromium-4.0.260.0.ebuild digest

10) Emerge it and watch as it fails miserably! (Or works! :O)
11) Spend the next few hours trying to figure out why it didn't work and fix it! (Or, if it worked, have a cup of tea! And a crumpet! With... nutella?)

keet · Post by **keet** » Sat Dec 05, 2009 11:37 am

I dislike Openoffice because it tends to fail, but then, it hasn't failed for me in a while. Nothing bothers me that much because usually the worst that happens is I set my computer to emerge --keepgoing overnight and I might need to emerge a couple things in the morning. I think most people here who have them agree that having a quad-core C.P.U. is great for Gentoo.

dextermagnific · Post by **dextermagnific** » Sat Dec 05, 2009 3:09 pm

Hey I forgot one : PyQt !!!!!!!
This is hell this package makes a python interface of every Qt header ! Needed for PyKDE, which is needed for plasma scripts. So for every KDE upgrade you may need to rebuild Qt and PyQt

Kollin · Post by **Kollin** » Sat Dec 05, 2009 3:40 pm

Qt and related

dufeu · Post by **dufeu** » Sat Dec 05, 2009 9:12 pm

Any toolchain changes.

'Nuff said.

Oh yes! patch-2.6 was indeed nasty! {shudders}

luispa · Post by **luispa** » Sat Dec 05, 2009 9:19 pm

Qt also.

Luis

eccerr0r · Post by **eccerr0r** » Wed Dec 23, 2009 10:30 pm

Things/Categories that I hate to emerge:

1. Baselayout and its dependencies, especially pam. Hell can break loose. Luckily I only experienced it with test systems.
2. gcc-x.y.z, where old gcc-a.b.c's a<x especially, and also b<y sometimes. This tends to cause breakage with libstdc++, glibc tends to be less of a problem, except that it tends to accompany a gcc bump.
3. Anything else where major version numbers changed, because breakage can happen.
4. ati-drivers. 'nuff said (binary)
5. Anything marked ~ especially multimedia libraries that haven't settled on a API ... but that's expected

I think my worst emerges to date:
1. The Expat ordeal - major breakage
2. gcc-3.6 (libstdc++) and gcc-4.0 (more libstdc++) - large breakage
3. ati-drivers breaking graphics due to kernel incompatibility.
4. xorg-server version bumps tend to be painful, X11 tends to be "core"
5. apache-1.3 to apache-2, php4 to php5, and mysql4 to mysql5 ... broke lots of functionality but at least core system didn't break and I expected the issues.

This is not to say there are a lot of horrible breakages to fix (like the device-mapper/lvm change, the ongoing ffmpeg issue, lots of e2fsprogs dependency changes such as libcom/libss, mplayer's dependencies, upgrading wine scares me as it could break a delicate system, etc ...)

I fear that upgrading Gnome will bite me once in a while too. Lots of little packages to determine which one's the culprit.

I tend to not fear "large" emerges, distcc and fairly quick machines tend to cover (like xulrunner I don't fear at all anymore...)

yngwin · Post by **yngwin** » Thu Dec 24, 2009 4:34 am

luispa wrote:Qt also.

Why? And how could we make it better?

regomodo · Post by **regomodo** » Thu Dec 24, 2009 10:55 am

yngwin wrote:
luispa wrote:Qt also.
Why? And how could we make it better?

I doubt you can. Qt is big and breaking it into sub-packages is as good as it'll get I reckon. I think the most intensive sub-package is qt-webkit and that seems to be the case for anything webkit (chromium for example).

dufeu · Post by **dufeu** » Mon Dec 28, 2009 7:06 am

yngwin wrote:
luispa wrote:Qt also.
Why? And how could we make it better?

Actually, I just went through the update to qt-webkit and thought it went very well. But I suspect some of the reason for why I thought that was because the wall clock time was, relatively speaking, reasonable.

Point of reference: the wall clock time to emerge the update to "evolution" was definitely more than twice as long as for qt-webkit. The evolution emerge apparently forces "-j1" and takes f o r e v e r to run. On my 4 core AMD Phenom II 9600, the length of time to emerge evolution is very disappointing.

Considering that qt-webkit source is more than 120 megs while evolution source is less than 30 megs ...

eccerr0r · Post by **eccerr0r** » Mon Dec 28, 2009 6:56 pm

C++ programs takes forever to compile.

I guess I don't feel too much pain, I've compiled evolution on my P3-1GHz...

I think my top four worst compiles to date, starting with #4:

#4: gcc 2.96, Solbourne OS/MP 4.0D/KAP 33MHz/8MB -- 4 hours
#3: NetBSD 1.2 kernel, DECstation 3100, 24MB -- 5 hours
#2: Linux kernel 0.99pl12, 386DX40-4MB swapping to a 2:1 interleave HDD -- 6 hours
#1: CenterICQ, DECstation 3100, 24MB -- 3 days (C++ code, and swaps VERY badly, 100+MB into swap)

Anything better than these is child's play... though I dare not compile OpenOffice, and xulrunner tends to merely be in the < 2 hour range...

And again I suppose compile time is nothing, just leave the computer do its job. The things that hurt is things that need user intervention to do, like fixing links that don't show up till half way through the compile, or after compiling and installing, everything ends up saying:

libexpat.so: not found

Hypnos · Post by **Hypnos** » Mon Dec 28, 2009 9:30 pm

* If an update causes massive breakage, it's either a bug or you screwed up.

* There is a logic behind Webkit's design. Web engines require front-ends for interfacing with browsers, but also back-ends to interface with the platform. xulrunner has a great number of dependencies like Xorg, Cairo+Pango, Alsa, etc. which are not portable to other platforms like Windows and Mac. It also has dependencies on nss and nspr which are redundant on many platforms.

By contrast, qt-webkit only depends on Qt -- no nspr or nss, no platform-specific libs. The idea is to "wrap" the web engine with the platform's core library (Qt, GNOME stack, Cocoa) to minimize complexity. WebKit devs only have to worry about WebCore and JSCore, port maintainers don't have to worry design compromises to accommodate sister ports, and packagers don't have to track a multitude of deps.

eccerr0r · Post by **eccerr0r** » Tue Dec 29, 2009 1:02 am

Hypnos wrote:* If an update causes massive breakage, it's either a bug or you screwed up.

It doesn't matter if it was a bug (portage problem, like libexpat.so) or caused by user error (which usually means, user forgot to *manually* change config files), it's still annoying!

The latter is probably _the_ most annoying thing about version bumps.

It still stands - If it could be emerged cleanly without user intervention, it's not an ebuild that I hate to emerge

Hypnos · Post by **Hypnos** » Tue Dec 29, 2009 4:07 am

I don't recall a situation where an upgrade involved following a procedure that wasn't unavoidable.

Acceptance brings peace.

warrens · Post by **warrens** » Sat Jan 02, 2010 6:59 pm

Packages I hate to emerge are...NONE

Shining Arcanine · Post by **Shining Arcanine** » Sun Jan 10, 2010 10:21 pm

tkhemili78 wrote:KDE, regardless of which version, I usually set to emerge overnight. That can be a real PITA if it hit an error during, then fix the error, and resume the emerge.... and wait. I once emerge Openoffice from the source. and that took a few hours. glibc would be a close third.

You can use --keep-going to help with that. It will do as much as it can do and then in the morning, you can deal with the ones that didn't compile. It is great when the error occurs in a small dependency tree and not so great when it occurs in a large dependency tree.

Quick23t · Post by **Quick23t** » Sun Jan 10, 2010 10:37 pm

Pretty much any specialty software, FreeCAD as an example has yet to actually compile or install correctly under Gentoo. Programs that have too small of a user base are always a problem..

regomodo · Post by **regomodo** » Sun Jan 10, 2010 11:16 pm

Quick23t wrote:Pretty much any specialty software, FreeCAD as an example has yet to actually compile or install correctly under Gentoo. Programs that have too small of a user base are always a problem..

It installed in amd64 for me and worked too. Freecad doesn't take that long to build but it's dependency -- opencascade, takes forever to build.

Quick23t · Post by **Quick23t** » Mon Jan 11, 2010 1:03 am

regomodo wrote:
Quick23t wrote:Pretty much any specialty software, FreeCAD as an example has yet to actually compile or install correctly under Gentoo. Programs that have too small of a user base are always a problem..
It installed in amd64 for me and worked too. Freecad doesn't take that long to build but it's dependency -- opencascade, takes forever to build.

I just tried it again last night and couldn't get it to install, I may have a dependency version problem. Are you on ~ or stable? I bought Solidworks so it's not critical that get freecad working. It would be nice though.

regomodo · Post by **regomodo** » Mon Jan 11, 2010 7:54 pm

Quick23t wrote:
regomodo wrote:
Quick23t wrote:Pretty much any specialty software, FreeCAD as an example has yet to actually compile or install correctly under Gentoo. Programs that have too small of a user base are always a problem..
It installed in amd64 for me and worked too. Freecad doesn't take that long to build but it's dependency -- opencascade, takes forever to build.
I just tried it again last night and couldn't get it to install, I may have a dependency version problem. Are you on ~ or stable? I bought Solidworks so it's not critical that get freecad working. It would be nice though.

Pretty much 90% (minus kde-4.3.4 packages) are stable.