Dne 14. 05. 24 v 2:03 Stephen Gallagher napsal(a):
On Mon, May 13, 2024 at 10:09 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a):On 5/13/24 16:09, Vít Ondruch wrote:Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):%patch otoh (now) is a regular (though internally implemented) macro that is expanded with other macros and though can be used in other macros and expressions.Do I read correctly that we can now use `%patch` in e.g. `%check` section? Interesting. Is this documented?No, while %patch and %setup *could* be made available elsewhere now, they are still only available in %prep because that's the only place where they make sense.Working with Ruby, which is interpreted language, there are cases where we want to patch tests, while we want to keep them in their original form in the package. This might sound weird, but the thing is that for running tests, we might be limited by infrastructure. E.g. Koji does not have internet access, builders are slow, etc. So we might want to apply some patch to workaround such issues. I have no hopes convincing you. But thank you for clarification.This last statement was unnecessarily hostile. You are better than that, Vit.
Sorry. What I wanted is just to explain some context and somehow said that while I would like have this possibility, I am not e.g. going to open upstream RFE ticket.
I assume that Panu's statement above - "that's the only place where they make sense" - was an unintentional overstatement and should have been read as "that's the only place we could think of where it made sense". You've now provided a reasonable argument for why %check might make sense. To expand on your example a bit, what I think you're saying is that in the case of Ruby, we ship not only the binary bits but also the Ruby tests in the RPMs. For sensible reasons, we want to deliver those unmodified from upstream, but we also want to be able to run them in the %check section which necessitates making some modifications due to the limitations and restrictions present in the Koji build system. By being able to constrain the patch application to the %check section (which, if I remember correctly is run AFTER the creation of the binary RPMs) means that we can package the unmodified sources without having to resort to custom trickery in the specfile (copying all the tests to a new location to modify them before running or some such). Is that a fair restatement of your use-case, Vit?
Right, that is fair.Thank you for taking time to make sure my use case is properly understood. Appreciate that.
Vít
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
