First off, the guidelines have:
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 <prais...@redhat.com> 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
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.
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org