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`.

Dne 05. 05. 22 v 19:35 Fabio Valentini napsal(a):

On Tue, Apr 26, 2022 at 1:50 PM Marián Konček <mkoncek@redhat.com> wrote:

Adding onto this, as I mentioned an additional step, I can also imagine
defining some macros which would be used in the .spec file. We could
have a simple generic one that would be available within rpm with the
extension possibility of each working group defining their own macros
which they would use in their own ecosystems.

Not everything has to be an RPM macro ... And I'm not even sure how
you would extract the value of these macros from the .spec file for
external consumption. Parsing RPM .spec files yourself is very hard,
and RPM's own spec parsing machinery doesn't really expose all that
much of its innards to the outside via its API.

I've spent a few minutes working on a DRAFT of my suggested
"SourceScript"-based functionality for spectool here:
https://pagure.io/rpmdevtools/pull-request/94

It was surprisingly simple to implement, works just fine, and
integrates with the default "spectool -g *.spec" use case.
It just calls the specified script with the value of the .spec file's
"Version" tag as an argument (making it unnecessary to parse the .spec
file in the script for a second time, just to extract the version
string again). Adding other CLI arguments (though I wouldn't know any
argument other than "%{version}" that would be useful here) would be
simple.

I'd be interested to see whether that would be enough to satisfy the
use case mentioned at the start of the thread, though I think the
current implementation should be flexible enough (maybe too flexible,
even).

Sorry, but I am not happy about that, because

1) the script is external to the .spec file

2) there still needs to be related `Source10: path-to-script.sh` to have the script included in SRPM.


Vít

Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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 to devel-leave@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