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/bl...
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`.
On 6. 5. 2022 11:36, Vít Ondruch wrote:
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email todevel-leave(a)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.fedora...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
--
Marián Konček