Panu Matilainen wrote:
On Fri, 13 Feb 2009, Ralf Corsepius wrote:
Panu Matilainen wrote:
On Fri, 13 Feb 2009, Michael DeHaan wrote:
Florian Festi wrote:
Ville Skyttä wrote:
As another solution for this problem we (ehm, Panu) will backport a
check that will make noarch packages (both regular and noarch) fail
to build if they contain binaries (==colored files==the right thing
to do even for emulators, bioses, cross compilers, ...[1]). This
additional check will be in place before koji will be updated [2].
I would prefer that, at least, there was a way to bypass this binary
file check in the specfile for apps that have a legitimate reason to
do it.
Yes, there's an override, precisely for these kind of reasons:
# Should binaries in noarch packages terminate a build?
%_binaries_in_noarch_packages_terminate_build 1
Turning that off in spec will make binaries in noarch packages
How is "binary" defined?
Currently it's only ELF executables and DSO's.
So you don't destinguish between native and foreign?
This would be a serious deficiency.
[Related to it: The current definition as being used by the debug-info
generation/build-id checks in Fedora's rpm are a PITA when it comes to
packaging cross-tools/cross-libraries]
You'd need to have debugedit and various other pieces available for the
cross target and setup rpmbuild to use those instead of the native ones
when cross-building.
Non applicable.
cross-tool packages typically contains binaries from several different
architectures.
Should mostly be possible even as it is, but most
likely find-debuginfo.sh and friends could use some further
parametrization to make it easier to do. Or just disable the
debuginfo/build-id & friends for cross-tools/libraries.
Making these
a) PATH-aware (e.g. according to FHS rules)
b) very restrictive on destinguishing "native" vs. "foreign"
is the only solution I am aware about.
(actually, a) is sufficient)
a warning, and it serves as documentation "yes we're doing something
a bit special, this is intentional" too.
Why does this check + warning exit all?
IMO, by marking a package/sub-package "noarch" the package's author
has clearly noted his intentions to be wanting the arch to be ignored.
Of cause this carries a risk of accidentally packaging native binaries
into supposed to be "noarch" packages, but these can pretty easily
be distinguished from "foreign binaries" by other means (e.g. by
restricting such checks to certain PATHs).
It's just a packaging sanity check, just like unpackaged / missing files
and such. Noarch package carrying arch-dependent binaries is a pretty
grave package error except for some corner cases such as where the
binaries are carried as "content", not something to execute on the host.
Your corner case is my standard use-case. Your "sanity check", from my
POV doesn't actually belong into rpm but into some external tool.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
