First off, the guidelines have: https://fedoraproject.org/wiki/Packaging:Guidelines#Noarch_with_unported_dependencies I've been assuming that you're talking about the BuildRequires: case. If you're just talking about the case where you can build it anywhere because you're just copying files around, but it just won't install, then you can try doing the noarch/ExclusiveArch: trick. To be fair, I have no idea if it still works; I recall that some people really didn't like it. Of course if it doesn't work then I'll remove that bit from the guidelines. I've sent out a couple of questions to folks who should know better than I. >>>>> "PR" == Pavel Raiskup <praiskup@xxxxxxxxxx> writes: PR> Understood why _usually_ do not permit them, but the fact we _never_ PR> permit them sounds like not-yet-fixed design issue. I can't imagine a situation where it would be acceptable for a user to type "dnf install foo" for something that's purely in Fedora and be greeted with an unsatisfied dependency error. I just can't. PR> That is not that trivial in case of this particular package, though. PR> Removing the (sub)package is easier for me... The "hack" you talk PR> about .. I have a difficult time believing that it would take longer than a minute to remove some BuildArch: statements and add ExclusiveArch: where necessary. PR> .. would be about not tagging such packages into repos of affected PR> architectures (that sounds wrong ..)? You still have to make sure that the packages are actually built on machines which can actually build the packages. That's actually not the same set of machines as the set of machines where the package would run. That's just something that needs to happen in the buildsystem. PR> Can you point me to that discussion(s)? The discussion has happened at various places over the history of the project, back to when PPC or somesuch was added and had no JVM support. In fact, I recall having a discussion about the true meaning of "noarch" back in the FC2-timeframe, but I just don't have references going back that far. Again, feel free to raise it with the buildsys people; I wouldn't be surprised if they have a canned response by now. - J< _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
