I would also be interested in this. In our set of java packages we have a few cases where upstream releases .jars with bundled binary files which either cannot be stored within .src.rpm files because of licensing issues or because they would be unreasonably large. Example here: https://src.fedoraproject.org/rpms/byte-buddy/blob/rawhide/f/generate-tarball.sh
Our scripts are mostly copy-paste with some additional removals where needed. This is in addition to the %prep step where we tend to remove some parts as well. I never questioned this approach but I agree that I would like to have it automated.
When repackaging, there are issues that need to be addressed and decided whether they pose a real problem like file attributes, file sorting, timestamps for example.
It looks like we would want some %pre-prep step :)
Dne 21. 04. 22 v 14:58 Miroslav Suchý napsal(a):
Dne 21. 04. 22 v 13:20 Vít Ondruch napsal(a):
Now I am looking for feedback about general approach. Of course it could be somehow polished and improved to hide some boiler plate.This part:
%{echo:%(
[ ! -e %{S:1} ] &&
Looks really clumsy. After reading the
https://pagure.io/packaging-committee/issue/1132#comment-769233
I like
# Script: gen_clean_tarball.shapproach. Whether it will be special comment, macro (with support for extraction in spectool) or new tag in RPM - I do not care. The important part is that it is standalone file, which can be easily locally executed. That would ease development and debugging.
1) Standalone script is kind of against RPM philosophy, where the idea always was that the .spec file should contain everything.
2) Standalone script does not solve the main issue and that is a way CI could obtain the tarball. Of course you mentioned "with support for extraction in spectool", but that is also part of the issue, because that would need the "spectool" changes as well as CI changes. My proposal does not need that. Of course, this is proof of concept, while the part of the script you point out could be possibly improved and abstracted by some macro.
Vít
Miroslav
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
-- Marián Konček
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
