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