On Wednesday, September 21, 2016 11:57:06 AM CEST Jason L Tibbitts III wrote: > >>>>> "PR" == Pavel Raiskup <praiskup@xxxxxxxxxx> 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 _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
