On Fri, May 6, 2022 at 12:17 PM Marián Konček <mkoncek@xxxxxxxxxx> wrote: > > I agree with Vit, I want to add to this: > > * still having to maintain a custom script is not an improvement over our current situation. > * make sure that $VERSION can be processed, there are cases when for example the tilde "~" needs to be swapped for dash "-". > * More complex case of $VERSION: obtain a specific commit from upstream, example: https://src.fedoraproject.org/fork/mkoncek/rpms/javapackages-bootstrap/blob/rawhide/f/javapackages-bootstrap.spec#_19 > > The only thing that needs to happen in this phase is removing files. Therefore there is no need to allow the flexibility like in the %prep stage. The whole function should look like this: > > `obtain_sources $processed_version $list_of_patterns_to_exclude` > > where $processed_version as well as $list_of_patterns_to_exclude can be written / computed directly in the .spec file. > > Like in "https://github.com/fedora-java/javapackages-bootstrap/archive/%{git_short_hash}.tar.gz"; > For $list_of_patterns_to_exclude, we generally want to exclude either specific files / directories or names based on their prefixes / suffixes. Basically we need the functionality of chained `rm` and `find ... -delete`. Isn't this starting to move goal-posts? I provided a draft implementation that solves 100% of the problem stated in this thread: A way to automate fetching / preparing arbitrary sources that is compatible and integrated with existing packaging workflows, and should be compatible with the CI stuff we have now. If you want something that is not a separate config / script file but embedded inside the spec file, you'd probably need to file an RFE with RPM for that, because currently you don't have enough access to RPM .spec parsing machinery to implement something like this, as far as I can tell. And even if you want to throw away all currently existing scripts and use something that's a limited, 100% declarative solution, you'd still need to integrate this into current packaging workflows somehow (probably in spectool). But spectool uses RPM python bindings to parse the .spec file, and that doesn't expose stuff like the values of macros, so you're back to either filing an RFE with RPM for adding APIs for that, or using an external config file. If you prefer a declarative approach using an external config file (instead of an external script) for spectool, I can work on that. Heck, I've been using a very similar tool to automate my COPR with nightly builds of Pantheon / elementary OS components for over half a decade. But the thing you seem to want (both *100% declarative* and *integrated in the .spec file*) is not currently possible, as far as I can tell (unless you start parsing .spec files yourself, which - trust me - is not something you want to do). Fabio _______________________________________________ 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
