Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux