Currently there is a QA check for shebang interpreters that warns about missing dependencies, but it doesn't handle the case when the interpreter is called via /usr/bin/env. So #!/usr/bin/python without python in dependencies would be caught, but #!/usr/bin/env python would not. QA could handle /usr/bin/env as a special case and do additional search for the interpreter binary in common binary paths - and print a warning if nothing was found, or the interpreter is not listed in dependencies.
This will require a change to rpmdeps as well as some higher level searching to correctly resolve the env entry since we need to search PATH.
I spoke with the RPM folks and they are interested in this feature as well. I'll be working with them. See here: http://rpm.org/ticket/136 and http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=e7f73133cbb35ed0f21938996018654391b0a7d7
Both links in Comment 2 appear to be dead?
http://rpm.org/ticket/136 is live again. The comment at the bottom is "fixed" but it seems more like a "won't fix". "04/24/15 08:03:57 changed by FlorianFesti status changed from assigned to closed. resolution set to fixed. RPM uses a simplified version of this that does not try to evaluate to the full patch for quite a while now. Guess we stay with this. Closing." Patch link is now: https://github.com/rpm-software-management/rpm/commit/e7f73133cbb35ed0f21938996018654391b0a7d7 Related: https://github.com/rpm-software-management/rpm/issues/136
It does look like RPM has basic support and I wonder if we could just use that. Even if RPM don't, that doesn't stop us doing this...
Hello, I am having a look. Can you say where the shebang is parsed. I have checked in the insane.bbclass but at that stage it seems we already lost what follows /usr/bin/env As an example, here is what we have in opkg: ``` tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/xz/5.4.1-r0/pkgdata-sysroot/runtime/opkg-utils:FILERDEPENDS:/usr/bin/opkg.py:opkg-utils: /usr/bin/env ``` My guess is that we have to change what remains in the FILERDEPENDS. I have not found where this is done
I also recently stumbled on this (because valgrind has failed to grow a python dependency even if some helper scripts have been rewritten from perl to python) and was also led down the rabbit hole of figuring out how the rpmdeps actually works. It seems unlikely we'll get something into rpmdeps upstream since they've had that # TODO: handle "#!/usr/bin/env foo" somehow for so many years. However, I think Yocto could still do something sensible. So just thinking out loud: Suppose we add a oe-core-only patch to rpmdeps that just adds a sed line that makes #!/usr/bin/env foo output "R interpreter/foo" (or "R interpreter:foo" or "R interpreter(foo)", whatever is easiest to handle later on and doesn't clash with, say, version dependency syntax). At first, the qa check is updated to ignore any dependency starting with interpreter/, just as it currently ignores "perl(". Then, for a subset of well-known possible values of foo (say, perl, python, python3, awk, gawk), the qa code is taught to translate interpreter/foo to /usr/bin/foo. All other foo values continue to be ignored. Maybe that interpreter/foo -> /usr/bin/foo should only be done with usrmerge DISTRO_FEATURE in effect - that should still help catch missing dependencies, since anybody building with that in effect would do the qa check. Alternatively, maybe the gawk recipe could be taught to RPROVIDE interpreter/awk, sort-of like the virtual/ namespace, then the qa code wouldn't need to do any translations (but may still need, for a while, to ignore all but a known set of foo values where the recipes have been updated with the RPROVIDE).
Created attachment 4984 [details] combined hacky patch Something like the attached seems to work. The QA check is hack-demoted to a warning just to avoid breaking builds left and right but still see what we'd get. As expected this gives quite a few warnings. Fx WARNING: slang-2.3.3-r0 do_package_qa: /usr/share/slsh/scripts/svnsh contained in package slang requires interpreter/slsh, but no providers found in RDEPENDS:slang? Probably the package should just grow a RPROVIDE interpreter/slsh , but I just did python3 and perl in the POC. WARNING: gobject-introspection-1.78.1-r0 do_package_qa: /usr/bin/g-ir-scanner contained in package gobject-introspection requires interpreter/python3, but no providers found in RDEPENDS:gobject-introspection? It has RDEPENDS on two python modules, so will probably pull in python3-core, but should probably have an explicit RDEPENDS (?) WARNING: glib-2.0-1_2.78.0-r0 do_package_qa: /usr/bin/gdbus-codegen contained in package glib-2.0-codegen requires interpreter/python3, but no providers found in RDEPENDS:glib-2.0-codegen? Had RDEPEND on python3, but that's an empty package that doesn't seem to pull in python3-core. Maybe that RDEPEND should just be changed to python3-core? WARNING: glib-2.0-1_2.78.0-r0 do_package_qa: /usr/bin/gtester-report contained in package glib-2.0-utils requires interpreter/python3, but no providers found in RDEPENDS:glib-2.0-utils? No RDEPENDs AFAICT, so needs fixing. WARNING: gdb-13.2-r0 do_package_qa: /usr/bin/gcore contained in package gdb requires interpreter/bash, but no providers found in RDEPENDS:gdb? WARNING: systemd-1_254.4-r0 do_package_qa: /usr/lib/systemd/systemd-update-helper contained in package systemd requires interpreter/bash, but no providers found in RDEPENDS:systemd? These seem legitimate, and should either be fixed by adding the bash dependency, or if undesired, split from the main package to somewhere else that could then have that dependency. But, maybe this isn't what we want at all.
I forgot to add: There are some cases where "#!/usr/bin/env python" is used, from the python3 recipe itself, e.g. WARNING: python3-3.11.5-r0 do_package_qa: /usr/lib/python3.11/cgi.py contained in package python3-netserver requires interpreter/python, but no providers found in RDEPENDS:python3-netserver? But AFAICT we're not shipping something like Debian's python-is-python3 providing a python->python3 symlink, so I don't know how that case should be handled. We can't very well pretend that python3-core provides interpreter/python when the package doesn't have a /usr/bin/python .
There's a patch attached, someone could send it to the oe-core list for review.
The path attached is only touching the RPM package. Do we need to also consider DEB package ?
(In reply to jeanbouch418 from comment #11) > The path attached is only touching the RPM package. Do we need to also > consider DEB package ? Never mind, I found the answer. The package.py recipe call rpm utility regardless.
The ideas in the patch are sound but the implementation needs some work and guidance. Dropping NEWCOMER.