Gentoo updating bad...

[pierric82]

It's worse everytime... trying to update the system is becoming hell.
Sometimes (many times already) a package has not the expected size (like a gtk+ package expected to be 300k...), sometimes the md5 is wrong, even redownloading the package.
Sometimes the configuration of the package fails, like lirc-0.8.0-r1 telling me the options should be different from now on.
Everytime the solution in the end is to mask the package in the new version, but that's not what I intend to do when updating my system.

In total, I've been trying to update for 3 days while I'm at work, and everytime the process stops somewhere for yet another reason. Not to speak of the fact that I will have to work 2 hours when I finally unmask X 7.0 ...

I guess a fresh install would help, but my idea when installing gentoo was that I would never have to do a fresh install, at least until my disk crashes.

Has anyone seen the amount of problems increase for the last few months?

Disappointed (and bored).
Pierric.

[lnxz]

I've found that most issues I've encountered while updating my system are easily solveable.
Even the upgrade to modular Xorg went quite smoothly for me.
Perhaps you should post details for specific issues so they could be resolved.

[pierric82]

Hello,

The trouble is that compiling all of this takes time. My objective is to start it in the morning, and have my PC shut down when it's done. But for 3 days, it has been compiling for a few hours only and then cancelled because of an error I could not have expected.

The quickest way to solve the problems is always to blacklist the package, but it's dirty.

One example was the Gtk+ 2.8.19 package, which had an expected size of about 300k, instead of something like 12M. Maybe because I have internet problems and the download failed? But I'd think the filesize would be stored with the checksums and download with the rest of the files during the emerge --sync step. I tried replacing every instance of the expected filesize in every file in the corresponding portage directory, but somehow it kept returning the same message, so I don't where it took the filesize from after all. And even if that had worked, I'd have had to replace the checksums as well, because at least the md5 was different.


Regarding today's lirc problem, here is the emerge output (when retrying to emerge lirc only, hence 1 of 1):

Calculating dependencies... done!
>>> Emerging (1 of 1) app-misc/lirc-0.8.0-r1 to /
>>> checking ebuild checksums
>>> checking auxfile checksums
>>> checking miscfile checksums
>>> checking lirc-0.8.0.tar.bz2
* Determining the location of the kernel source code
* Found kernel source directory:
* /usr/src/linux
* Found sources for kernel version:
* 2.6.12-gentoo-r6
*
* Compiling only the lirc-applications, but no drivers.
* Enable drivers with LIRC_DEVICES if you need them.
*
* LIRC_OPTS is deprecated from lirc-0.8.0-r1 on.
*
* Please use LIRC_DEVICES from now on.
* e.g. LIRC_DEVICES="serial sir"
*
* Flags are now set per use-flags.
* e.g. transmitter, hardware-carrier
* These options are no longer allowed to be set
* with LIRC_OPTS: --with-driver=hauppauge

!!! ERROR: app-misc/lirc-0.8.0-r1 failed.
Call stack:
ebuild.sh, line 1555: Called dyn_setup
ebuild.sh, line 668: Called pkg_setup
lirc-0.8.0-r1.ebuild, line 183: Called die

!!! LIRC_OPTS is no longer recommended.
!!! If you need support, post the topmost build error, and the call stack if rel
evant.



I don't remember it but I guess I had a problem with xine-lib as well at some point because my packages.mask file contains "media-libs/xine-lib-1.1.2_pre20060328-r9".

Everytime it's a full day with the PC on, sucking energy and heating the room for nothing. And then, since I dont have so much time to investigate, I usually only blacklist the package, rendering the update concept quite useless.

Cheers,
Pierric.

[lnxz]

If you know to make bash scripts it's fairly simple to make emerge continue emerging even though one of the packages fail, while logging the failing package for later inspection.

The gtk+ thing could be solved by either deleting the distfile, or by recreating the digest (you should only do this if you trust the distfile to be clean).

[pierric82]

Yes I agree, individually problems can be solved. But then I could install everything by hand :-/ Ok, that's a bit extreme and it's still handy to have the emerge tool... but I have a feeling it worked better 2 years ago than it does now. Somehow.

Regarding the bash script, that's a good idea, but how would you do it? and what if it's something most of the other packages rely on?

Regarding Gtk, I did both: delete the distfile, download it from a website and tried to modify the digests. However I tried to do it manually, because I didnt know how to do it with ebuild. Thanks for the tip.

Thanks for your help,
Pierric.

[lnxz]

If you create a list of packages to update (emerge -Dvup world + sed and grep) you could do something like this

[maltheus]

[pierric82]