On our systems it seems like revdep-rebuild now honors the default opts in make.conf. This might have happened due to this bug: http://bugs.gentoo.org/show_bug.cgi?id=289599 However options like --buildpkg (which is in our make.conf as default option) do not make sense whatsoever for a revdep-rebuild. Consequently rr finds a lot of broken packages but does nothing because the binaries are already up to date. We see this behavior on all our machines and it especially makes the move to openssl-1 very tedious. At least a switch to tell rr's emerge to ignore the default opts would be nice. (We this is not an error on our side) Cheers Martin Reproducible: Always Steps to Reproduce: 1. break intalled packages i.e. move to openssl-1 2. run revdep-rebuild (with --buildpkg in default opts) 3. rr will find lots of broken stuff Actual Results: rr/emerge reinstalls squat Expected Results: rr/emerge should filter/not honor --buildpkg
Sorry of course we meant --usepkg not --buildpkg. The latter is actually wanted :)
Some information: EMERGE_DEFAULT_OPTS="--reinstall=changed-use --usepkg --buildpkg --verbose" Versions: Portage 2.1.8.3 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.11.2-r0, 2.6.35-gentoo x86_64) gentoolkit 0.2.4.6.1-r1
It is very reasonable that revdep-rebuild honors --usepkg: This way the binaries which you built on another system for the revdep-rebuild will get installed. Why else should you use --usepkg as *default* options if not for building everything on another system? Of course, you can ignore the default options: Either call EMERGE_DEFAULT_OPTS= revdep-rebuild or use revdep-rebuild -- --ignore-default-opts
(In reply to comment #3) > It is very reasonable that revdep-rebuild honors --usepkg: > This way the binaries which you built on another system for the revdep-rebuild > will get installed. > Why else should you use --usepkg as *default* options if not for building > everything on another system? Okay. I do not think that this is reasonable though. Because there is no way of telling if the binary really fixes the broken linkage (except running a check again and in that case rebuild from source but that needs to be done manually). The --buildpkg makes sense in combination with this new portage feature: http://blogs.gentoo.org/zmedico/2010/03/03/rebuilt_binaries_portage_2_1-8 but not at this point with a stable portage. And even then does the feature not ensure that the linkage is correct after this "newer" binary is installed. > Of course, you can ignore the default options: Either call > EMERGE_DEFAULT_OPTS= revdep-rebuild > or use > revdep-rebuild -- --ignore-default-opts > Yes the first works the second doesn't. try it yourself. rev-rebuild will just call emerge with --ignore-default-opts just to append the default opts afterwards. This is in my opinion still a flaw that breaks rr's functionality. The "fixes" are basically just workarounds and in the current state rr is just useless without a workaround if you have usepkg in your default opts.
Please see the following bugs: bug 281655 bug 282474 bug 289599 As you can see, this has been discussed extensively and is something of a "you can't make everyone happy" problem. Probably the best solution would be if revdep-rebuild would output a warning when it sees certain flags in EMERGE_DEFAULT_OPTS.
(In reply to comment #5) > Please see the following bugs: > > bug 281655 > bug 282474 > bug 289599 > > As you can see, this has been discussed extensively and is something of a "you > can't make everyone happy" problem. Actually #1 and #2 make a case in my point. #3 is also not really giving a dire need for rr using the default opts. This is also not a matter "make everyone happy" or "personal preference". This behaviour basically makes rr's functionality undefined and IMHO a little dangerous. If you use --usepkg/--usepkgonly not only might rr do nothing but even worse maybe it does indeed update the binary but the linkage is still broken. rr's manpage: <snip> DESCRIPTION revdep-rebuild scans libraries and binaries for missing shared library dependencies and attempts to fix them by re-emerging those broken bina ries and shared libraries. It is useful when an upgraded package breaks other software packages that are dependent upon the upgraded package. </snip> ATM rr's it no longer doing what is in the description. it should not read: revdep-rebuild scans libraries and binaries for missing shared library and MAYBE attempts to fix them by calling emerge with default opts on the broken packages. [...] Wheather or not revdep-rebuild will actually fix the linkage depends on your default options: [A list with possible outcomes of rr and what to do then] > Probably the best solution would be if revdep-rebuild would output a warning > when it sees certain flags in EMERGE_DEFAULT_OPTS. > That would only be a very convenient solution for a developer. For the user the bahaviour should either be: Filter options like --usepkg etc and let the user append it to rr if he really wants them. In that case give a warning that this is dangerous and that rr needs to be run at least twice. -- or -- Revert to the "old" behaviour. If this will stay rr's behaviour it's fine by me and I will make a shell script as a workaround. I think I have made my point though. Cheers Martin
(In reply to comment #3) > Why else should you use --usepkg as *default* options if not for building > everything on another system? e.g. to build packages that don't exist on the first machine that happens to want that package installed. then an rsync cron job will distribute the generated binary to other servers. please fix revdep-rebuild to not use binary packages, it defeats the whole purpose of revdep-rebuild. it isn't even possible to pass --usepkg=n to revdep-rebuild, since it is inserted into the command-line before the default opts from make.conf.
*** Bug 451448 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > it isn't even possible to pass --usepkg=n to > revdep-rebuild, since it is inserted into the command-line before the > default opts from make.conf. Is that fixed since bug 307023?
(In reply to comment #9) > (In reply to comment #7) > > it isn't even possible to pass --usepkg=n to > > revdep-rebuild, since it is inserted into the command-line before the > > default opts from make.conf. > > Is that fixed since bug 307023? I can confirm that at least I can overwrite the default options like follows: "revdep-rebuild -- --usepkg=n". Nevertheless, that should be added by default.
This is a WONTFIX, I'm not going to filter the flag in revdep-rebuild. I used to filter flags in revdep-rebuild and all I got was a lot of grief over it. I'm not going to go that route again.
Then how about this: You could support an own (optional) environment variable, or a special config file, where one could define emerge options that will eventually override EMERGE_DEFAULT_OPTS. Then one could set that variable to "--usepkg=n", which will override a potential "--usepkg=y" in EMERGE_DEFAULT_OPTS. That should be fine with everyone, you don't need to filter anything and we could set up our wanted options.
Created attachment 335660 [details, diff] 0001-Add-REVDEP_DEFAULT_OPTS-variable-to-allow-overriding.patch This patch adds support for REVDEP_DEFAULT_OPTS in make.conf and the environment. It still allows you to override the options on the command-line.
This is now in the git repository and can be tested with gentoolkit-9999 with revdep-rebuild.sh Here is the man page entry for the variable: REVDEP_REBUILD_DEFAULT_OPTS - List of default emerge options for revdep-rebuild The REVDEP_REBUILD_DEFAULT_OPTS variable can be used to override EMERGE_DEFAULT_OPTS for revdep-rebuild. This variable replaces the val- ues of EMERGE_DEFAULT_OPTS and can still be overridden by command line options. Please note that this variable is only for options to pass to emerge and not options for revdep-rebuild itself. I still need to add support for the variable to the python version of revdep-rebuild.
Test successful! Works great for me. Thank you! IMHO a big step forward in these arguments about what flags should be overridden or used in revdep-rebuild. Now everyone can use their own setting.
why do we even need to change anything ... it all works with the current revdep-rebuild: EMERGE_DEFAULT_OPTS="" revdep-rebuild -q -i -- --quiet --quiet-build --with-bdeps=y --binpkg-respect-use=y --usepkg=n --getbinpkg=n (from https://github.com/zenops/cookbooks/blob/master/cookbooks/portage/files/default/scripts/updateworld#L103)
(In reply to comment #16) > why do we even need to change anything ... it all works with the current > revdep-rebuild: > > EMERGE_DEFAULT_OPTS="" revdep-rebuild -q -i -- --quiet --quiet-build > --with-bdeps=y --binpkg-respect-use=y --usepkg=n --getbinpkg=n And you are willing to type all of that everytime you want to call revdep-rebuild? In Gentoo, so many things are controllable with config files or environment variables, then why should a tool like revdep-rebuild not be?
no, i'm not willing to type this, that's why i've added it to my updateworld script ... it doesn't make any sense at all to call python-updater, perl-cleaner, @preserved-rebuild, revdep-rebuild or lafilefixer manually anyway, so why not script all of it ... i'm not against the proposed change to revdep-rebuild. i'm just saying that it works with the current version too
(In reply to comment #16) > why do we even need to change anything ... it all works with the current > revdep-rebuild: The short answer is we don't *need* to change anything. The long answer is support was easy to add and it should stop any more complaints about revdep-rebuild and EMERGE_DEFAULT_OPTS.
