On Wednesday, September 21, 2016 11:57:06 AM CEST Jason L Tibbitts III wrote:
"PR" == Pavel Raiskup praiskup@redhat.com writes:
PR> Here comes the same argument as with ExclusiveArch .. I don't want PR> to, because this _is_ noarch package and _is_ expected to work on PR> all arches, at some point.
It's not noarch, sorry. It doesn't work on all architectures, regardless of whether it has any compiled code.
Argh, yes. I've updated my noarch definition. "noarch" is not about content.
Sounds like there are two types of such noarch-looking non-noarch packages :), first which is expected to work everywhere at some point and the second where we know immediately that it will never work by it's definition.
For the first type of package, using ExclusiveArch is really just ugly work-around and additional work for packagers.
PR> If I blacklist some arches today, I'll likely never enable the PR> package for the blacklisted architectures.
Nothing technical prevents you from doing so. If the issue is whether you'll remember, I'm not sure what to suggest. I have the same problem, but it's unrelated to packaging, so....
Taking into account how easy (and consistent) is to remove that (sub)package, I tend to do that instead now. And that is :( in general, because that package could be useful to someone.
I don't think this point is unrelated to packaging though ... packaging tools should protect packagers from doing mistakes.
PR> Is it wrong to simply let things as are? Does it hurt some process PR> in Fedora (except for additional traffic in my INBOX)?
Yes, people using those architectures will have a package they cannot install. We don't permit such broken dependencies in the distribution.
Understood why _usually_ do not permit them, but the fact we _never_ permit them sounds like not-yet-fixed design issue.
There has been talk before of some hack to make packages like this still pretend to be noarch, but since the proper solution is so simple (remove BuildArch: noarch and add ExclusiveArch:) there's not really been much incentive to implement it.
That is not that trivial in case of this particular package, though. Removing the (sub)package is easier for me... The "hack" you talk about ..
I do see this become more of an issue with every new arch bringup unless they have rather complete coverage. The mere presence of some minor architecture shouldn't force a bunch of packages to suddenly become archful. Feel free to talk to the buildsys and releng folks about it (again).
.. would be about not tagging such packages into repos of affected architectures (that sounds wrong ..)? Can you point me to that discussion(s)?
Thanks, Pavel