I am stuck in a loop where portage recommends running this command forever: 'emerge @preserved-rebuild' I understand it is due my recently removing nss, and =www-client/firefox-bin-72.0.1 ebuild not statinng that it depends on dev-libs/nss. I guess this would apply to all firefox-bin versions. BR Arnaud
Short: I am quite sure it is something different. Reopen, if I was wrong. It is sad to read that you have problems with the software. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/
# revdep-rebuild entry insinto /etc/revdep-rebuild echo "SEARCH_DIRS_MASK=${MOZILLA_FIVE_HOME}" >> ${T}/10${PN} doins "${T}"/10${PN} The package already masks the firefox-bin directory as it uses the bundled nss. Please provide `emerge --info firefox-bin`
Created attachment 603820 [details] emerge --info firefox-bin
If you all could have a look as to why the revdep-rebuild entry is being ignored would be appreciated.
(In reply to Arnaud Vallette d'Osia from comment #0) > I am stuck in a loop where portage recommends running this command forever: > 'emerge @preserved-rebuild' What do you have in /var/lib/portage/preserved_libs_registry? (In reply to Jory A. Pratt from comment #4) > If you all could have a look as to why the revdep-rebuild entry is being > ignored would be appreciated. It's a portage preserve-libs issue, so the revdep-rebuild config is not going to help with this.
(In reply to Zac Medico from comment #5) > (In reply to Arnaud Vallette d'Osia from comment #0) > > I am stuck in a loop where portage recommends running this command forever: > > 'emerge @preserved-rebuild' > > What do you have in /var/lib/portage/preserved_libs_registry? > { "dev-libs/nss:0": [ "dev-libs/nss-3.46.1", "2021", [ "/usr/lib64/libnssutil3.so", "/usr/lib64/libnss3.so", "/usr/lib64/libsmime3.so", "/usr/lib64/libssl3.so" ] ] }
> What do you have in /var/lib/portage/preserved_libs_registry? NSS version and order apart, this looks the same here : { "dev-libs/nss:0": [ "dev-libs/nss-3.47.1-r1", "16141", [ "/usr/lib64/libsmime3.so", "/usr/lib64/libnss3.so", "/usr/lib64/libssl3.so", "/usr/lib64/libnssutil3.so" ] ] }
Normally I would suggest for the firefox-bin ebuild to use patchelf --set-rpath as suggested in the documentation for portage's new unresolved soname QA check: https://gitweb.gentoo.org/proj/portage.git/commit/?id=d5dbe58beb5a4e73b919c7dbe8ed4d7b75a860f0 However, the unresolved soname QA check does not detect any problem for firefox-bin because all of the required sonames are clearly provided (they all appear in the PROVIDED metadata that portage generates for firefox-bin). Therefore, I think we can adjust portage preserve-libs handling to exempt any sonames which appear in the PROVIDED metadata that portage generates.
Patch posted for review: https://archives.gentoo.org/gentoo-portage-dev/threads/2020-02/ https://github.com/gentoo/portage/pull/505
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=0edb0cd52e25a3ce168f712258ded9ccc6a5bee4 commit 0edb0cd52e25a3ce168f712258ded9ccc6a5bee4 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-02-08 19:43:27 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-02-08 22:49:24 +0000 preserve-libs: generate implicit rpath for bundled libs (bug 705736) In order to account for internal library resolution which a package may implement (useful at least for handling of bundled libraries), generate implicit runpath entries for any needed sonames which are provided by the same owner package. For packages that have bundled versions of system libraries, this will prevent preserve-libs from unecessarily preserving system libraries as reported in bug 705736. For the www-client/firefox-bin-72.0.2 package, this adds an implicit /opt/firefox runpath entry to 15 files. Bug: https://bugs.gentoo.org/705736 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/util/_dyn_libs/LinkageMapELF.py | 63 ++++++++++++++++++++++++----- 1 file changed, 54 insertions(+), 9 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=87db6ee1103dc33c206111288a43ac619d27cefc commit 87db6ee1103dc33c206111288a43ac619d27cefc Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-02-09 01:18:34 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-02-09 01:31:22 +0000 sys-apps/portage: Bump to version 2.3.88 #649622 prevent unecessary installation of virtual/w3m followed by removal by depclean #705736 preserve-libs: prevent unecessary preservation of system libraries which a package bundles #707820 generate API documentation with sphinx-apidoc #708448 support FEATURES=qa-unresolved-soname-deps so that the QA warning from bug 704320 can be disabled #708660 phase-helpers.sh: avoid passing an empty root value to portageq when ebuild IPC is disabled Bug: https://bugs.gentoo.org/706142 Bug: https://bugs.gentoo.org/649622 Bug: https://bugs.gentoo.org/705736 Bug: https://bugs.gentoo.org/707820 Bug: https://bugs.gentoo.org/708448 Bug: https://bugs.gentoo.org/708660 Package-Manager: Portage-2.3.88, Repoman-2.3.20 Signed-off-by: Zac Medico <zmedico@gentoo.org> profiles/arch/riscv/package.use.mask | 2 +- sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-2.3.88.ebuild | 271 +++++++++++++++++++++++++++++++++ 3 files changed, 273 insertions(+), 1 deletion(-)
I'd like to close this bug, but I still see portage complaining: I guess I should remove /var/lib/portage/preserved_libs_registry? Is it proper to do so? just rm? Thanks!
(In reply to Arnaud Vallette d'Osia from comment #12) > I'd like to close this bug, but I still see portage complaining: I'd expect it to recognize that the libraries are unneeded and eliminate them automatically, so it sounds like something needs to be fixed here. I'll try to reproduce the issue. > I guess I should remove /var/lib/portage/preserved_libs_registry? > Is it proper to do so? just rm? > Thanks! You need to remove the preserved files as well, or else they'll remain on your system and they won't be tracked by portage.
(In reply to Zac Medico from comment #13) > > I guess I should remove /var/lib/portage/preserved_libs_registry? > > Is it proper to do so? just rm? > > Thanks! > > You need to remove the preserved files as well, or else they'll remain on > your system and they won't be tracked by portage. Also, don't remove them if the're provided by a legitimate package with an entry in /var/db/pkg/dev-libs/nss-*. Please attach /var/db/pkg/dev-libs/nss-*/CONTENTS if it exists. If the libraries are really preserved then they need to be eliminated from that file as well.
Thanks. If the tool is supposed to nuke those files and clear the list, I'll wait for it to do so and give you the confirmation then.
Since Portage 2.3.89, emerge @preserved-rebuild doesn't complain anymore : nice. But /var/lib/portage/preserved_libs_registry still list the same files, and said files are still present.
(In reply to Arnaud Vallette d'Osia from comment #16) > Since Portage 2.3.89, > emerge @preserved-rebuild > doesn't complain anymore : nice. This means that dev-libs/nss is not installed, and there's no /var/db/pkg/dev-libs/nss-*/CONTENTS referencing the preserved files, correct? > But /var/lib/portage/preserved_libs_registry still list the same files, and > said files are still present. If the answers to my above questions are yes, then normally the preserved libraries should be automatically eliminated the next time that you install or remove any package. Are they still present after you install or remove any package?
> This means that dev-libs/nss is not installed, and there's no > /var/db/pkg/dev-libs/nss-*/CONTENTS referencing the preserved files, correct? Right and right > If the answers to my above questions are yes, then normally the preserved > libraries should be automatically eliminated the next time that you install > or remove any package. Right again, this is a peculiar behavior tough, that emerge @preserved-rebuild would not do the job, but emerging anything would... In my opinion. Should I open another bug? Thanks, closing.
(In reply to Arnaud Vallette d'Osia from comment #18) > > If the answers to my above questions are yes, then normally the preserved > > libraries should be automatically eliminated the next time that you install > > or remove any package. > > Right again, this is a peculiar behavior tough, that > emerge @preserved-rebuild > would not do the job, but emerging anything would... In my opinion. > Should I open another bug? Now that you've upgraded portage, you shouldn't be able to enter this state ever again. So, if it resolves itself during the next package install/upgrade/removal, then the problem is effectively resolved.
Right again, thanks !
