Heads up: Noarch Subpackages
Ralf Corsepius
rc040203 at freenet.de
Sat Feb 14 17:06:56 UTC 2009
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
More information about the fedora-devel-list
mailing list