FS#43600 - makepkg does not strip read-only files

Attached to Project: Pacman
Opened by Peter Wu (Lekensteyn) - Tuesday, 27 January 2015, 21:18 GMT
Task Type Bug Report
Category makepkg
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 4.2.0
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Summary and Info:
While trying to build openssl with debugging symbols, I was surprised to find a libcrypto.so.1.0.0 that grew from 2.8M to 9.8M. It turns out that all debug symbols were still present, even when the 'strip' option is set.

Somehow OpenSSL thought it would be nice to install libraries with 555 permissions... and they are in the minority of doing this. This results in makepkg skipping this file for strip consideration:

find . -type f -perm -u+w -print0 2>/dev/null | while read -rd '' binary ; do
case "$(file -bi "$binary")" in

Is there actually a use case for not stripping a binary while the "strip" option is given...?

Steps to Reproduce:
1. extract the attached tarball
2. makepkg
3. notice that "foo" is missing in the pkg/foo-debug/ dir.
This task depends upon

Comment by Allan McRae (Allan) - Tuesday, 27 January 2015, 22:23 GMT
I am sure this is a duplicate and we decided not to fix this.
Comment by Peter Wu (Lekensteyn) - Tuesday, 27 January 2015, 22:27 GMT
What is the reasoning? A comparison of strip vs no strip showed that the stripped libcrypto.so.1.0.0 is missing filenames in symtab. A look on a Ubuntu system reveals no *.so file under /usr which is unreadable for the owner.

Here is a trivial patch that unconditionally makes files have a writable mode for their owner. It probably won't be accepted as-is, but perhaps a discussion can start now?
Comment by Allan McRae (Allan) - Tuesday, 27 January 2015, 22:54 GMT
If an upstream developer installs a file as unwritable, that is either intentional or needs fixed upstream.

We can change it to writable for stripping as long as the permissions are reverted afterwards.
Comment by Moritz Bunkus (mbunkus) - Saturday, 11 August 2018, 10:00 GMT
For the record, this also affects a lot of Perl packages containing native libraries as ExtUtils::MakeMaker installs files read-only by default.
Comment by Eli Schwartz (eschwartz) - Sunday, 12 August 2018, 05:46 GMT
And perl itself for that matter.

I've mentioned this to Bluewind on IRC, and suggested it might be a good idea to try discussing the reasoning of the perl developers in doing things like this. But he did not have sufficient time to chase this down; would you be interested in doing so?

I agree with Allan that it's quite weird for upstream to install files as read-only for root, and we should not mess with this ourselves.

Loading...