Chiming in here, as I am unfortunately affected by this relatively rare problem.
On 2020-03-29 14:21 +0200, Niels Thykier wrote: > Luca Boccassi: >> Control: tags -1 patch >> >> On Fri, 2020-03-27 at 11:56 +0000, Luca Boccassi wrote: >>>> [...] >>> >>> I face the same problem - a static library built on Jan 28th was >>> stripped correctly, but one built on March 26th is now ignored by >>> dh_strip because perl thinks it's a text file. The library has no >>> diff >>> between the two builds. >>> >>> Once manually stripped, diffoscope reports this difference between >>> the >>> two libraries: >>> >>> [...] >>> >>> >>> Not sure how it detects the file type, and why it changes from ArFile >>> to StaticLibFile (or what's the difference between the two). >>> >>> Old package with librte_pmd_virtio_crypto.a stripped correctly: >>> >>> http://snapshot.debian.org/package/dpdk/19.11-3/#libdpdk-dev_19.11-3 >>> >>> New package with librte_pmd_virtio_crypto.a unstripped: >>> >>> https://salsa.debian.org/paelzer-guest/dpdk/-/jobs/630625/artifacts/file/debian/output/libdpdk-dev_19.11.1-1+salsaci_amd64.deb >> >> Opened MR on Salsa to add a fallback on file --mime-type when perl -B >> fails: >> >> https://salsa.debian.org/debian/debhelper/-/merge_requests/37 >> > > Hi Luca, > > Thanks for the proposed patch. > > At this point, I would rather slowly move away from the use of file(1) > and am more interested in a patch that avoided new uses of file. > > The primary issue is that debhelper's design is not a good match with > programs with a "slow" upstart time. This leads to "weird" work arounds > to avoid the "penality" for running the program (e.g. as was done with > ELF binaries until compat 12 where we finally started doing the right > thing). Would it be possible to use libfile-libmagic-perl here and in other cases where debhelper currently uses file(1)? At least that would save the overhead of process creation. Cheers, Sven