On Mon, May 13, 2024 at 10:09 AM Vít Ondruch <vondr...@redhat.com> 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.

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?
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to