Question about revdep-rebuild

[sidamos]

There is one thing I don't understand about portage: Why does revdep-rebuild not rebuild everything needed?

I just did a big update (250 packages) and then ran revdep-rebuild, which did rebuild some packages.

In the past, I always ignored the messages from some packages after emerge, that I had to rebuild for a specific lib and then manually delete that lib, because I thought revdep-rebuild does this. I mean these kind of messages:

revdep-rebuild --library '/usr/lib/liblber-2.3.so.0' && rm '/usr/lib/liblber-2.3.so.0'

So, because it was many of them this time, I actually did it and for some of them it really rebuilt some packages.

If revdep-rebuild can't/won't do this and I haven't done it manually in the past, can I somehow find out which ones to rebuild and delete? Or is the only way a system rebuild?

On another system, I am using portage alpha, which creates nice rebuild sets. I guess, the same applies there (have to manually rebuild/delete for some libs)?

Thanks!

[Logicien]

I think a way to advoid to have to rebuild packages after upgrade, is to use the --deep (-D) switch who consider in the package calculation the reverse dependancies that are not set explicitly in the ebuild.

The output message that tell to rebuild the package for a specific library do revdep-rebuild only for that library. The command revdep-rebuild without any --library option do it for the dependancies of all packages and then should include the rebuild of any broken library. So, you should not have to specify any library for it to be consider by revdep-rebuild.

After that, you can use emerge -acv to remove all packages that are not in the world set and are not a dependancy of a package who is in the world set. Sometime, is have to stop this command before it proceed to put a package that will be remove in the world set with the --noreplace (-n) of emerge. I never do it for libraries that are by definition dependancies only.

Than I reexecute the command emerge -acv who must be done at the end of an upgrade process. That way, I generally never have to delete a file or a package manually after an upgrade. I delete only those packages I explicitly installed myself that are not part of the system and I do not want anymore. I can have to delete some packages that help emerge to proceed for an upgrade. I reinstall those I want after the upgrade.

I would prefer to find the package who contain a library (equery b /usr/lib/liblber-2.3.so.0) and remove it if it is really needed instead of removing any file of a package manually, unless it is not part of any package.
_________________
Paul

[sidamos]

Hmm, I always use the --deep switch for a world update. Then I do revdep-rebuild -i. Still, some of the single revdep-rebuild for specific libs did some package building afterwards.

[dol-sen]

The reason revdep-rebuild does not rebuild those pkgs for libfoo.so.x that the messages tell you after the pkg is merged, is because it isn't broken until the lib is removed. It was not removed when the pkg was unmerged to protect your system from breakage.

That is why you need to run revdep on that lib, then delete the olld lib. Revdep does not look for those saved libs unless specified. It looks for broken lib links.

Because you don't run revdep for those libs, they will hang around your system till they are manually removed. The pkgs that depend on them will gradually be upgraded and most of the time depend on the new lib. But sometimes the presence of the old lib prevents that. Remember the libpng-1.4 issue? To clean those up you will have to do it manually, checking each lib it it has a pkg that it belongs to. The ones that don't, run revdep-rebuild on them and delete them.

Anyway, portage-2.2 had the @preserved-rebuild feature which would let you tell emerge to rebuild those pkgs. It usually woked fine, but had some bugs that kept it from going stable. It was also not a final solution. The final solution is now in EAPI 5 ebuilds that can specify subslots. The subslots will contain info about the ABI of the lib and will trigger an automatic rebuild of affected pkgs. Eliminating the normal need for revdep-rebuild and @preserved-rebuild.

Revdep-rebuild will hopefully only be needed for actual breakage, not breakage due to upgrading. That will also take time for all pkgs in the tree to be upgraded for that new feature. I would expect that to be complete in about a year. It is being done on an upgrade basis, not a convert now policy. In the meantime you will be getting less and less of those types of revdep messages.
_________________
Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

[sidamos]

Thanks a lot for this great explanation!