Building neovim-0.10.0 shows this QA notice: > * QA Notice: Unresolved soname dependencies: > * > * /usr/bin/nvim: /usr/lib64/lua/5.1/lpeg.so > * As a result, `revdep-rebuild` ends up mistakenly thinking that neovim needs a rebuild (see https://github.com/gentoo/gentoolkit/pull/49) I suspect that `lpeg.so` is a module, and not something that should be directly linked against.
Comparing with 0.9.5-r1: > framework /var/tmp/portage/app-editors # scanelf -n neovim-0.10.0/image/usr/bin/nvim > TYPE NEEDED FILE > ET_DYN libluv.so.1,libvterm.so.0,/usr/lib64/lua/5.1/lpeg.so,libmsgpack-c.so.2,libtree-sitter.so.0,libunibilium.so.4,libluajit-5.1.so.2,libm.so.6,libuv.so.1,libc.so.6 neovim-0.10.0/image/usr/bin/nvim > framework /var/tmp/portage/app-editors # scanelf -n neovim-0.9.5-r1/image/usr/bin/nvim > TYPE NEEDED FILE > ET_DYN libluv.so.1,libtermkey.so.1,libvterm.so.0,libmsgpack-c.so.2,libtree-sitter.so.0,libunibilium.so.4,libluajit-5.1.so.2,libm.so.6,libuv.so.1,libc.so.6 neovim-0.9.5-r1/image/usr/bin/nvim "lpeg" doesn't even appear in neovim-0.9.5-r1's build.log.
I'm guessing that https://github.com/neovim/neovim/commit/45bcf8386918bbb475fbe20c48b508aa89ed0624 is the upstream commit that made this change.
https://github.com/neovim/neovim/commit/9f9cef1b569e226a87c5c74e455bc4fc76cc2fac I think this is relevant as well.
Is there a way to blacklist things for revdep-rebuild? Indeed that ljpeg change that Michael points too looks like the culprit, but not sure what to do about it.
(In reply to Scott Ellis from comment #4) > Is there a way to blacklist things for revdep-rebuild? Indeed that ljpeg > change that Michael points too looks like the culprit, but not sure what to > do about it. See the gentoolkit github PR linked from comment 0. I'm not aware of another way. (At the same time, using revdep-rebuild has been extremely rare for me in the last 10 years or so)
You can add stuff in /etc/revdep-rebuild. I had a file that contained LD_LIBRARY_MASK="nvim" at first, but I felt like that was abusing it, so I looked into a better solution.
(In reply to Michael Cook from comment #6) > You can add stuff in /etc/revdep-rebuild. I had a file that contained > LD_LIBRARY_MASK="nvim" at first, but I felt like that was abusing it, so I > looked into a better solution. Yeah putting `LD_LIBRARY_MASK="/usr/lib64/lua/5.1/lpeg.so"` isn't restrictive enough (since it applies to all packages). Good times.
*** Bug 938311 has been marked as a duplicate of this bug. ***
reproducible with app-editors/neovim-0.10.1-r1
Hey folks, this one still persists with app-editors/neovim-0.11.0 > * QA Notice: Unresolved soname dependencies: > * > * /usr/bin/nvim: /usr/lib64/lua/5.1/lpeg.so > * What can we do about it, or have it move forward. Also didn't notice any update on https://github.com/gentoo/gentoolkit/pull/49. correabuscar says that the PR works. Can we merge https://github.com/gentoo/gentoolkit/pull/49?
The issue is (still) that it's not clear if that's really right in gentoolkit and whether neovim should be fixed to not link against it if lpeg.so is a module. I don't know enough about Lua to say how normal module finding works, and whether simply dropping the linking against ljpeg.so is enough, or if some Lua code needs to be changed in neovim too.
(In reply to Sam James from comment #11) > The issue is (still) that it's not clear if that's really right in > gentoolkit and whether neovim should be fixed to not link against it if > lpeg.so is a module. > > I don't know enough about Lua to say how normal module finding works, and > whether simply dropping the linking against ljpeg.so is enough, or if some > Lua code needs to be changed in neovim too. (... so that it does a lookup via whatever mechanism is normally used in Lua.)
(and "works" obviously means "lpeg functionality works in neovim" too.)
