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 :)
On 25. 4. 2022 10:41, Vít Ondruch wrote:
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.sh
approach. 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@lists.fedoraproject.org
To unsubscribe send an email todevel-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 on the list, report
it:https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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 on the list, report
it:https://pagure.io/fedora-infrastructure
--
Marián Konček
_______________________________________________
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 on the list, report it:
https://pagure.io/fedora-infrastructure