This comes up fairly frequently, and I've found examples over the past half-decade with no apparent consensus on the right approach. If I've missed a guidelines, feel free to point it out.
Sometimes, a noarch package has a dependency on a binary package which doesn't exist for all architectures. Sometimes, it's even a build requirement. How should this be handled?
The two approaches I've seen are:
I haven't seen but can imagine a third approach, where a stub package is built on the problematic architecture -- either for the missing base binary dep ''or'' with a series of conditionals in the noarch package evading the requires or buildrequires and generating an empty package with just a readme.
There may be others. Neither of these really seem right. I particularly would like the noarch packages to actually stay that way, but most of all I want to know the official, consistent approach.
Thanks!
Another approach would be to enhance RPM and associated tools and the buildsystem to understand what is meant by ExcludeArch on noarch packages.
I think the only approach that works now is combining both 1 and 2, make it arch'd, and match the arches that it's dependencies support.
Hmmm. So, for a package where this isn't a problem on all Fedora primary archs, would it be okay to do the normal noarch thing in Fedora but make the package binary and use ExcludeArch on the EPEL branch (where PPC is primary)?
So, judging by your last comment you're in exactly the same boat our nodejs packages are in. The V8 JIT (and therefore the nodejs interpreter) doesn't work on PPC, but PPC is primary for EPEL.
We've gone with the option 2 you describe, [https://lists.fedoraproject.org/pipermail/nodejs/2013-June/000039.html on advice from a laundry list of packaging and rel-eng experts].
That accomplished two things: it keeps nodejs-foo packages from being mashed in PPC repos and stopped the ~200 broken dependencies on PPC e-mails I had been getting weekly up to that point.
One lingering issue is that koji still hands off noarch nodejs packages to PPC builders from time-to-time, but resubmitting them is only mildly annoying. Plus, ever since ARM got added to primary koji that pretty much just stopped happening. (That has to be coincidental since EPEL doesn't build on ARM, but hey, I'm not complaining. ;-) Maybe it actually got fixed and nobody told us?)
''ARCH ALL THE THINGS'' really isn't an option for us. It makes it much more difficult for lay users to tell the difference between the "real" arched nodejs packages, thus making mass rebuilds of such packages more difficult. Instead of a minor annoyance for packagers (oh noes, I have to resubmit a build from time to time!), we're instead pushing the problem out to mirrors, who now need three copies of the exact same content instead of one hardlinked one, and confusion to users (why is this ''javascript'' stuff ''arch-specific''??). I mean, for one-off packages it's probably fine, but it's really ugly when you're talking about an entire language stack.
I'm not quite sure how your third proposal would work. If an empty package in place of the buildrequired package would work, why have !BuildRequires on it in the first place?
I technically know about this but its rare enough that I keep forgetting...
It'd be an about three-liner patch to make rpmbuild special-case noarch packages to look at %_host_cpu instead of %_target_cpu wrt !ExcludeArch/ExclusiveArch but that risks breaking special cases depending on the current behavior and doesn't seem quite right either. Might be better to add new exclude/exclusive tags that are on %_host_cpu instead, or something.
@panu: I agree -- new exclude/exclusive tags for this case seem like the right plan.
Until that happens, FPC is working on documenting the workarounds. I'll write something up based on the nodejs stuff this week. Rest of FPC noted a few things in addition (Requires: should work out of the box with that strategy. BuildRequires are what cause problems. I'll document that resubmitting the job is an option and making packages archful would be another. If we go from archful to noarch between Fedora releases, [say -- because an arm port occurs] then we'd need Obsoletes.)
@mattdm: Re: "would it be okay to do the normal noarch thing in Fedora but make the package binary and use ExcludeArch on the EPEL branch (where PPC is primary)?" Yep. No need for a guideline to do that.
Okay, here's a draft:
https://fedoraproject.org/wiki/User:Toshio/Noarch_with_unported_dependencies
It can go in the Architecture Support section of the Guidelines after Architecture Build Failures: http://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support
Results of today's meeting:
fail-and-resubmit was rejected as a valid means of handling this. So people that are relying on that should think about updating their packages. New packages should not rely on it (instead, they should be made arch-specific until the needed packages are ported). The reasoning was that fail-and-resubmit causes harm during mass rebuilds which cannot differentiate between true failures and failures that are only a result of building on an invalid architecture.
We also talked about whether koji could be modified in any way to workaround this problem -- even if implementing it required a new, special file in the git repos. CC'ing Dennis to get input as to whether anything like this is possible as a longer term fix.
Written into the Guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dependencies
Announcement text:
"""
A method of handling noarch packages which have dependencies that are not present on some architectures was made official. https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dependencies These methods are a change from the common practice in, for instance, node.js packaging. Packagers should think about updating their packages to the new guidelines as they make other updates.
Please see https://fedorahosted.org/fpc/ticket/355#comment:8 or the meeting log for that date if you want more information than is in the Guidelines. The possibility of enhancing rpm or koji to deal with this in a better manner is being looked into by the packaging-team and rel-eng. When those features eventually are available to Fedora, we'll update the Guidelines to take advantage of them.
Metadata Update from @mattdm: - Issue assigned to toshio
Login to comment on this ticket.