On Wednesday, September 21, 2016 11:57:06 AM CEST Jason L Tibbitts III wrote:
>>>>> "PR" == Pavel Raiskup
<praiskup(a)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