I don't understand this "preserved rebuild" / epl thing

[thurnax]

I get this message after an emerge update:

[Josef.95]

Please try this --> https://forums.gentoo.org/viewtopic-p-8133466.html#8133466

[thurnax]

Too late.

I managed to get rid of most errors by emerge --oneshot on most of these packages except emacs and binutils. So I unmerged those packages to try to re-emerge them. Now both packages fail to rebuild. When trying to build binutils, I get this output:

[krinn]

I just hate preserved-libs, it cause more trouble than solve.
What is good with preserved-libs is that it preserved libraries that are use by some packages, preventing these packages from been broken.
What is bad with preserved-libs is that it keep useless libraries in your system until any packages using them are gone. But until this is done, portage will complains about the useless libraries.

I think the first idea behind it was good (prevent packages from breaking), but someone didn't deep think about the result.
In gentoo early days, when no preserved-libs exists, packages were just broken, and users might have hard time fixing that.
It was nightmare when broken packages were critical for the system (gcc is one good example with mpfr)

But it was early days, and emerge have two cool things today that were lacking: revdep-rebuild and binary package.

I highly prefer my system that just break the package and do remove the old library.
It's healthy that a package is broken because the old library is gone, it first force to solve any package issue that cannot run with the newer version and stop using an old library (that could be buggy or have cve issue).

You can run revdep-rebuild -L oldlib.soname to have emerge rebuild packages that are using the old lib, just the same as preserved-libs except you have 0 complain from portage this time.

You can set FEATURES="-preserved-libs" to remove this useless and bugging feature and get back to old days handling, but with revdep-rebuild tool that will ease the job.
You can set FEATURES="buildpkg" to enable binary building of your package, allowing you to re-install that infamous old lib your package wants in a second to fix it's broken status if affect package was critical (if gcc is broken because of mpfr, you could reinstall binary package of mpfr and your old gcc that depends on it to get back in time and have a system that still can build ; upto you then to find a way to fix that, but with a working system). But that just for such a case of a critical tool, you will in real just never use binary because of that, but binaries of your package would solve you one day or another.

[krinn]

For your (now) issue, look at eselect binutils list and select the 2.28 to fix your symlinks and make them pointing to the newer tools (as is a binutil tools), and emerge is certainly complaining that as-2.25 is gone.

And if you didn't install binutils-2.28 prior removing older 2-25, you're in the case where binary package would had save your ass.
If you have done that, either use a livecd to get a working toolchain, or try seek a 2-28 binary and install it to have a working toolchain, or seek a 2-25 binary to restore your toolchain and upgrade to 2-28 with it.
Yeah, binutils is a critical tool for your toolchain, you should just never remove any, upgrade first and let emerge remove it after the upgrade.

[thurnax]

binutils is now completely gone. "eselect binutils list" returns absolutely nothing, not even an error message.

I'm not sure what to do with a LiveCD let alone how one can get a working toolchain from it. I have searched through the Gentoo handbook for clues. Found none. I'm in the system right now, perhaps I could fetch a stage3 tarball and extract missing files from it?

'emerge -K binutils' doesn't work.

[krinn]

go with the livecd, mount your system in its /mnt/gentoo like when you prepare the chroot.
all you need to do is building the binary version of binutils that you could then re-use for yourself after.
which mean PKGDIR=/mnt/gentoo/usr/portage/packages quickpkg binutils
PKGDIR= will tell portage where to store the binary, so in your own disk and at a position where the package binary will be seek.
Then chroot and do emerge -pvk =binutils-version-from-the-livecd to check it will use it and install it

[NeddySeagoon]

krinns method in the chroot requires that you can install binutils without binutils already installed.
I don't know if it works or not.

There is another way without the use of the chroot but its not reccomended until all else has failed.
Post back if you need it.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[thurnax]

It took me some thinking. I thought at first that I should mount the liveCD and then chroot into that and build the binaries from there. Then I booted from the LiveCD, compiled binutils there. It compiles in that environment without problems, but I cannot get the binaries to get stored in the chrooted environment.

Am I to understand that I have to change the PKGDIR= line in /etc/portage/make.conf to:

[krinn]

[thurnax]

Yes, I got it back and everything compiles again. I managed to figure it out after googling for "gentoo binary package" and found that doc page I mentioned in my prior post.

But when dealing with this update process and cleaning things out you run into issues. So when you manage to fix one issue, you have at the same time broken something else ...


Now something has turned weird with the vmware-tools. The most important functionality of vmware tools is that it adjusts the desktop screen resolution to the size of the window it is running in or to the native resolution when in full-screen mode. Now I have a small window in the middle of my monitor that I cannot change.


I don't know what that binutils package has done to accomplish this. Even GRUB is low-res now (the GRUB_GFXMODE=1680x1050 line is still there in the GRUB config). I used to have a high resolution mode when booting up but that is now completely gone.


I used to install vmware-tools manually through vmware's virtual CD-ROM, but have given up with later versions since they complain that '/usr/bin/gcc' is not a valid binary and no valid linux headers are found in '/usr/src/linux' even though I took steps to build headers... But now there is a 'vmware' repository in the layman/overlay so I emerged it as a package from there. Alas, that didn't resolve the issue with the screen resolution. I'm not even sure whether it installed properly as it returned the warning: "You should set VMWARE_GUEST in make.conf to specify which operating systems you need." I did set VMWARE_GUEST="linux" and even added the USE flag vmware_guest_linux but the warning remains and 'emerge --info' doesn't show the USE flag "vmware_guest_linux" in the information.

[krinn]

The right tool, the right function.
It also works for the forum, the right topic, the right help

While i'm aware of your new problem, i didn't came here for that, and have no idea about vm-ware trouble, and vm-ware specialist might not seen this thread, because it's a thread about preserved-libs.

I'm just trying to say: open a new thread, with the right topic, and you might attract vm-ware helpers, and so, help yourself.

[thurnax]

Ok will do, it's just that this problem is related to the revdep-rebuild and one problem leads to another...

I highly doubt that a vmware specialist is interested in Gentoo unfortunately. Ubuntu, SUSE, Red Hat and perhaps Debian yes, Gentoo and Arch no

[NeddySeagoon]

thurnax,

A lot of virtualisation issues are common across hypervisors.
A new problem deserves a new topic anyway.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.