Panu Matilainen wrote:
<sigh/> I consider this to be more a temporary ugly cludge, but a generally feasible approach.On Fri, 27 Feb 2009, Thibault North wrote:Le Friday, 27. February 2009 12:02:24 pm Florian Festi, vous avez écrit :Panu Matilainen wrote:%global _binaries_in_noarch_packages_terminate_build 0Yup, that's the way to turn to turn it off from a spec.Looks like it is not enough (same error). (Have put it right after %description)Me thinks you have a typo in there somewhere, I just tried a mock rebuild of avr-libc and this makes it build just fine (it'll warn about the binaries but it wont stop the build):--- avr-libc.spec 24 Feb 2009 03:43:26 -0000 1.3 +++ avr-libc.spec 28 Feb 2009 08:55:23 -0000 @@ -1,3 +1,5 @@ +%global _binaries_in_noarch_packages_terminate_build 0 +
1) You are still invoking find-debuginfo.sh .../usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/avr-libc-1.6.4
... What is running find-debuginfo.sh on noarch packages supposed to do?In theory, there may-be cases where some kind of "debuginfo" extraction on noarch packages may make sense, however I am not aware of rpm's/Fedora's find-debuginfo.sh doing anything useful on noarch packages.
2) Your approach doesn't cover the case of packages which contain different kind of binaries, e.g. native, foreign and scripts (noarch) at the same time.
How would you want to handle this?So far, the only functional trick I am aware about is to hack find-debuginfo.sh/brp-strip etc. from inside of rpm-specs such that these tools do not run their "finds" in places they are not supposed to look into.
This works fine, as long as packages don't mix up native and foreign binaries into the same directory. But if they do, things become really nasty.
Real world example: Older cross-GCCs do so, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=485416 Ralf