-
|
Previously find-debuginfo was a part of RPM, so I hope it's okay to ask this question here. I want to know the history behind why find-debuginfo.sh operates only on exec files. This makes things a bit difficult while generating debuginfo package of kernels. |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments
-
|
Hi @pmatilai, any inputs on the above issue? RPM post install script might do the permission changes post gathering debuginfo data but installing .so files with 644 permission is a valid case. Can you please provide some info. I need to know if this should be handled at individual spec level or can be fixed in find-debuginfo tool itself. Thanks. |
Beta Was this translation helpful? Give feedback.
-
|
(Just FYI, @pmatilai is on vacation until August.) This is a convention (at least on Linux) for shared libraries to be executable. It's also mandated by Fedora Packaging Guidelines. I'm not familiar with the actual reasoning behind it but a quick google search gives some clues. As to why find-debuginfo.sh only looks for those that are executable: Looking at the git log, this check apparently has been in place since the very first version of the script added in 2002 (commit 90b34cd). That said, the original brp-strip-shared script (no longer included, see commit fd51922), on the other hand, does not have this filter (and instead mentions in a cryptic comment that "our libraries aren't +x"). So that's quite confusing. In any case, you may want to ask about this at https://sourceware.org/debugedit/ (which is where find-debuginfo.sh is nowadays shipped). I personally don't think anybody would change this now (without a very good reason) after those 20+ years. Even if the check itself turns out to be non-sensical, it should be considered a "feature" at this point because changing it would inevitably break somebody's packages, possibly in non-obvious or undetected ways. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the background and insights @dmnks. @pmatilai, please let us know if you have any further points on this. Or else I will proceed and close the discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Enabling brp-elfperms (which disables the executable bits in recent rpm versions) seems to be an error to begin with, at least on modern Linux. According to @fweimer all shared objects must be executable: https://lists.rpm.org/pipermail/rpm-list/2023-March/002093.html It also gets it wrong sometimes: #2496 As for why debuginfo mechanism is tied to it, probably "historical" (the easiest ballpark estimate of what to process) to begin with, and also used as a heuristic for dependency generation back then. But that's just a guess, this all predates my involvement by several years. It's also pretty much the only chance for packages to control debuginfo behavior per-file. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the response @pmatilai, if I have understood it right |
Beta Was this translation helpful? Give feedback.
-
|
The raison d'etre of brp-elfperms is to strip permissions from files that don't need it, so it's more like the whole script should just be disabled. If you build + ship your own rpm on Linux, then I'd recommend you do just that. For the time being I mean. |
Beta Was this translation helpful? Give feedback.
-
|
Noted, thanks for all the inputs and suggestions. Have a nice time ahead. |
Beta Was this translation helpful? Give feedback.
The raison d'etre of brp-elfperms is to strip permissions from files that don't need it, so it's more like the whole script should just be disabled. If you build + ship your own rpm on Linux, then I'd recommend you do just that. For the time being I mean.