revdep-rebuild - Still useful / recommended?

[amauk]

Non-support question. Just curious.

Running revdep-rebuild is just part of my update process,
but I can't for the life of me remember when it last picked anything up.
Any rebuilds needed seem to be picked up and handled by portage itself.

Was just wondering if running revdep-rebuild as part of a usual update process is still useful / recommended.

What I don't want is to get into a situation where I'm running deprecated / discouraged stuff because I wasn't paying attention.

Ta

[CaptainBlood]

It is required when emerge requires to do so.

It is true that some of such package rebuilds are done automagically.
But only because their ebuilds have directive(s) causing automatic rebuild under some circumstances.

Not all ebuilds are complete in this respect.

As long as you don't revdep-rebuild when requested, some former version of software will remain in the system, although newer is installed.
Each former version will be deleted as soon as all their revdep-rebuild counterpart(s) have been rebuild (against the latest version).

revdep-rebuild can be tested with -p(retend) e.g. to check how much work it will cause.

The rebuild(a) can be achieve at atomic level.
The order of the rebuild may be important to care of.

Thks 4 ur attention, interest & support.

[pietinger]

This tool is obsolete and "it's also considered a bug if a package relies on this" says our developer @Ionen here:
viewtopic-p-8686939.html#8686939

[amauk]

This tool is obsolete and "it's also considered a bug if a package relies on this" says our developer @Ionen here:
viewtopic-p-8686939.html#8686939

Noted.
Many thanks

[Hu]

It is true that some of such package rebuilds are done automagically.
But only because their ebuilds have directive(s) causing automatic rebuild under some circumstances.

I don't think this is correct. The preserved-rebuild feature handles this automatically, without ebuild directives. Perhaps you are thinking of subslot dependencies, which are used in an ebuild to force a rebuild when one is needed, but the soname does not indicate such.

As long as you don't revdep-rebuild when requested, some former version of software will remain in the system, although newer is installed.

revdep-rebuild finds cases where a consuming library is linked to a non-present provider. If the former version remained installed, revdep-rebuild would not flag the consuming package as broken, and would do nothing.

[Ionen]

To add more, haven't used Gentoo for *that* long, but in the 6 years I've used it I haven't ran revdep-rebuild even once and all my systems are fine I know it used to be needed some time before that, but that was a long time ago.

That tool is also hardly maintained as it can be noted by the long list of open bugs:
https://bugs.gentoo.org/buglist.cgi?qui ... ep-rebuild
(esp. tend to get confused by some systems and constantly want to rebuild the same thing, not to say everyone is affected by these issues)

Arguably it should be dropped entirely, albeit could have some obscure use cases even if not needed per se and it been left alone for now. Won't push for its removal, but if someone wants to I wouldn't object.

[Hu]

Although I rarely use it, one special use of it that I see as worth keeping is the --library=filename mode, which forces it to find things that would be broken if the named library were to be absent, without checking whether the library is actually absent.

[CaptainBlood]

It is required when emerge requires to do so.

Sorry I mixed up with

Code: Select all

Use emerge @preserved-rebuild ... prompt

My apologizes...

Thks 4 ur attention, interest & support.

[logrusx]

Last time I remember using it was because of buggy gcc update like 3 or 4 years ago. There was a gcc update which needed to be reverted and revdep-rebuild was the thing that automatically found what had to be rebuilt.

Best Regards,
Georgi

[bstaletic]

I also don't remember using revdep-rebuild recently. @preserved-rebuild is working great.

Are we saying revdep-rebuild's ability to be given a shared object for revdep consistency scan is also obsolete?

Code: Select all

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 1.25 s (backtrack: 0/20).

[ebuild   R    ] sys-libs/glibc-2.40-r5

Code: Select all

 * This is the new python coded version
 * Please report any bugs found using it.
 * The original revdep-rebuild script is installed as revdep-rebuild.sh
 * Please file bugs at: https://bugs.gentoo.org/
 * Collecting system binaries and libraries
 * Checking dynamic linking consistency

Your system is consistent

Code: Select all

 * This is the new python coded version
 * Please report any bugs found using it.
 * The original revdep-rebuild script is installed as revdep-rebuild.sh
 * Please file bugs at: https://bugs.gentoo.org/
 * You are not root, adding --pretend to portage options
 * Checking dynamic linking consistency
 * Assign files to packages

emerge /lib/libm.so.6 --pretend --oneshot --complete-graph=y media-libs/libpng:0/16 x11-drivers/xf86-input-libinput:0 dev-libs/isl:0/23 dev-lang/python:3.13 sys-process/procps:0/0-ng dev-python/pycryptodome:0 dev-libs/glib:2 net-wireless/wpa_supplicant:0 media-libs/libass:0/9 x11-libs/libxcb:0/1.12 dev-libs/libksba:0 media-libs/imlib2:0 sys-apps/pciutils:0 app-misc/tmux:0 sys-apps/grep:0 media-gfx/scrot:0 dev-build/cmake:0 app-crypt/p11-kit:0 dev-libs/expat:0 media-gfx/graphite2:0 dev-libs/libgpg-error:0 net-libs/miniupnpc:0/18 dev-libs/libassuan:0/3.0 media-libs/libvpx:0/9 dev-vcs/git:0 app-portage/portage-utils:0 sys-apps/ripgrep:0 sys-libs/libcap:0 media-libs/freetype:2 media-libs/openjpeg:2/7 x11-libs/libXft:0 net-misc/rsync:0 x11-libs/cairo:0 sys-devel/gcc:14 sys-devel/clang:19/19.1 net-libs/libnatpmp:0 app-crypt/gpgme:1/11.6.15.2 x11-libs/gtk+:3 www-client/librewolf:0/130 media-libs/libwebp:0/7 media-libs/harfbuzz:0/6.0.0 dev-libs/mpc:0/3 dev-libs/libinput:0/10 sys-apps/less:0 net-libs/libnsl:0/3 www-client/links:2 app-crypt/libb2:0 app-crypt/pinentry:0 sys-apps/shadow:0/4 net-misc/curl:0 app-crypt/gnupg:0 media-libs/libglvnd:0 x11-libs/gdk-pixbuf:2 sys-apps/systemd-utils:0 dev-libs/nss:0 app-text/mupdf:0/1.24.8 sys-fs/e2fsprogs:0 x11-libs/libdrm:0 net-libs/gnutls:0/30.30 dev-libs/openssl:0/3 app-arch/libarchive:0/13 media-video/ffmpeg:0/58.60.60 sys-apps/coreutils:0 dev-libs/mpfr:0/6 app-crypt/rhash:0/1 dev-libs/libgcrypt:0/20 sys-libs/libseccomp:0 dev-libs/libpcre2:0/3 dev-util/gtk-update-icon-cache:0 dev-libs/libxslt:0 media-gfx/feh:0 media-libs/tiff:0/6 x11-libs/pango:0 sys-apps/util-linux:0 app-editors/vim:0 media-libs/fontconfig:1.0 net-p2p/transmission:0 dev-libs/gmp:0/10.4 sys-apps/man-db:0 dev-libs/nettle:0/8-6 net-libs/libpsl:0 dev-libs/libtomcrypt:0/1 sys-libs/ncurses:0/6 media-video/mpv:0/2 media-sound/alsa-utils:0.9 x11-base/xorg-server:0/21.1.13 media-libs/mesa:0 dev-libs/nspr:0 dev-debug/gdb:0 net-misc/wget:0 net-misc/openssh:0 dev-libs/libevent:0/2.1-7 dev-util/pkgconf:0/5 sys-apps/file:0 media-libs/libjpeg-turbo:0/0.2

These are the packages that would be merged, in order:

Calculating dependencies  ... done!
Dependency resolution took 4.42 s (backtrack: 0/20).

[ebuild   R    ] sys-libs/ncurses-6.4_p20240414 
...
[ebuild   R    ] media-gfx/scrot-1.11.1 
[ebuild   R    ] media-gfx/feh-3.10.3 
[ebuild   R    ] x11-libs/gdk-pixbuf-2.42.12 
[ebuild   R    ] media-video/mpv-0.39.0 
[ebuild   R    ] dev-util/gtk-update-icon-cache-3.24.42 
[ebuild   R    ] x11-libs/gtk+-3.24.42-r1 
[ebuild   R    ] www-client/librewolf-130.0.1_p1 

[Chiitoo]

Although I rarely use it, one special use of it that I see as worth keeping is the --library=filename mode, which forces it to find things that would be broken if the named library were to be absent, without checking whether the library is actually absent.

This is what I have used it for at least a few times in ages past.

Build everything linking with 'libQt6Core.so.6' for example.

It has been helpful while testing packages (especially "live" packages), but of course this is a bit of a special use-case. :]