Hi,
I am preparing replacement of versioned MODULE_COMPAT_ requires by dependency generators. More details about the change can be found in mail thread [1].
The dependency generator, which I have prepared for Fedora, does not work for EPEL.
I would like to help maintainers who prefer one version of the spec file for all releases, if it is possible.
Could be the following file added to the package epel-rpm-macros (or anything like this) for EPEL 9? $ cat perlcompat.attr %__perlcompat_requires() %{lua: local path = rpm.expand('%1') local perl_ver = rpm.expand('%{perl_version}') if path:match('.+%.so$') and perl_ver ~= "" then print('perl(:MODULE_COMPAT_' .. perl_ver .. ')') else print('perl-libs') end } %__perlcompat_path ^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+
But I don't know how to do it for EPEL 7/8, because the above file doesn't work. It ends with error [2]: error: Couldn't exec perl-libs: No such file or directory
Do you have any idea if there is any other way how to provide maintainers this functionality for EPEL 7/8?
Thanks for any advice, Jitka
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2] https://download.copr.fedorainfracloud.org/results/jplesnik/perl-epel/centos...
On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
Could be the following file added to the package epel-rpm-macros (or anything like this) for EPEL 9?
It could, but it might be better to include this in a subpackage of epel-rpm-macros or as a separate perl-generators-epel component. We could pull it in with (package-name-here if perl-generators). This won't work in EPEL 7 which unfortunately doesn't support rich dependencies.
But I don't know how to do it for EPEL 7/8, because the above file doesn't work. It ends with error [2]: error: Couldn't exec perl-libs: No such file or directory
Do you have any idea if there is any other way how to provide maintainers this functionality for EPEL 7/8?
Parametric macro dependency generators are not supported in EPEL 7 and 8's RPM versions. You can still implement this using a "regular" dependency generator. This is also described in the RPM documentation[1]. Instead of specifying %__perlcompat_requires() and writing an RPM macro that accepts a path name as %1, you specify `%__percompat_requires /path/to/executable`. That script receives a newline separated list of paths as stdin and prints the generated dependencies to stdout separated by newlines.
So perlcompat.attr could look something like
``` %__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version}
# %%__perlcompat_path can stay the same. ```
These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is passed to the script as an argument, because the script of course doesn't have access to the RPM context. This can be any executable written in any language, but it should be straightforward to do this in shell.
[1]: https://rpm-software-management.github.io/rpm/manual/dependency_generators.h...
-- Maxwell G (@gotmax23) Pronouns: He/Him/His
Parametric macro dependency generators are not supported in EPEL 7 and 8's RPM versions. You can still implement this using a "regular" dependency generator. This is also described in the RPM documentation[1]. Instead of specifying %__perlcompat_requires() and writing an RPM macro that accepts a path name as %1, you specify `%__percompat_requires /path/to/executable`. That script receives a newline separated list of paths as stdin and prints the generated dependencies to stdout separated by newlines.
So perlcompat.attr could look something like
%__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version} # %%__perlcompat_path can stay the same.These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is passed to the script as an argument, because the script of course doesn't have access to the RPM context. This can be any executable written in any language, but it should be straightforward to do this in shell.
Thank you for your advice.
The dependency generator would be added to perl-srpm-macros which is in buildroot of Fedora. So, I prepared package perl-srpm-macros-epel which should work for EPEL 7/8/9. If you want to check it please look at https://jplesnik.fedorapeople.org/perl-srpm-macros-epel/
I checked it in Copr https://copr.fedorainfracloud.org/coprs/jplesnik/perl-epel/.
If the change is approved by FESCo, I'll prepared the review for the package. Then I'll ask you for adding it to epel-srpm-macros.
Regards, Jitka
On 06. 12. 22 15:02, Jitka Plesnikova wrote:
The dependency generator would be added to perl-srpm-macros which is in buildroot of Fedora.
Why not perl-generators instead?
On 12/7/22 12:17, Miro Hrončok wrote:
On 06. 12. 22 15:02, Jitka Plesnikova wrote:
The dependency generator would be added to perl-srpm-macros which is in buildroot of Fedora.
Why not perl-generators instead?
You are right, I'll have to add it to perl-generators. It requires perl-macros which provides definition of paths used in %__perlcompat_path since rpm 4.15. Jitka
Hi,
I added the package perl-generators-epel to EPEL 7/8/9. The package is adding the behavior provided in perl-generators-1.16.
I created pull requests for epel-rpm-macros to add perl-generators-epel to EPEL buildroot.
Pull Request EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/61 EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/60 EPEL 9: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/59
Could anybody please merge them and build the packages or shall I do it myself?
Thanks, Jitka
On 12/6/22 04:40, Maxwell G via epel-devel wrote:
On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
Could be the following file added to the package epel-rpm-macros (or anything like this) for EPEL 9?
It could, but it might be better to include this in a subpackage of epel-rpm-macros or as a separate perl-generators-epel component. We could pull it in with (package-name-here if perl-generators). This won't work in EPEL 7 which unfortunately doesn't support rich dependencies.
But I don't know how to do it for EPEL 7/8, because the above file doesn't work. It ends with error [2]: error: Couldn't exec perl-libs: No such file or directory
Do you have any idea if there is any other way how to provide maintainers this functionality for EPEL 7/8?
Parametric macro dependency generators are not supported in EPEL 7 and 8's RPM versions. You can still implement this using a "regular" dependency generator. This is also described in the RPM documentation[1]. Instead of specifying %__perlcompat_requires() and writing an RPM macro that accepts a path name as %1, you specify `%__percompat_requires /path/to/executable`. That script receives a newline separated list of paths as stdin and prints the generated dependencies to stdout separated by newlines.
So perlcompat.attr could look something like
%__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version} # %%__perlcompat_path can stay the same.These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is passed to the script as an argument, because the script of course doesn't have access to the RPM context. This can be any executable written in any language, but it should be straightforward to do this in shell.
-- Maxwell G (@gotmax23) Pronouns: He/Him/His _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 31, 2023 at 10:19:09AM +0100, Jitka Plesnikova wrote:
Hi,
I added the package perl-generators-epel to EPEL 7/8/9. The package is adding the behavior provided in perl-generators-1.16.
I created pull requests for epel-rpm-macros to add perl-generators-epel to EPEL buildroot.
Pull Request EPEL 7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/61 EPEL 8: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/60 EPEL 9: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/59
Could anybody please merge them and build the packages or shall I do it myself?
Done. Building now.
Thanks for the pr's
kevin --
Thanks, Jitka
On 12/6/22 04:40, Maxwell G via epel-devel wrote:
On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
Could be the following file added to the package epel-rpm-macros (or anything like this) for EPEL 9?
It could, but it might be better to include this in a subpackage of epel-rpm-macros or as a separate perl-generators-epel component. We could pull it in with (package-name-here if perl-generators). This won't work in EPEL 7 which unfortunately doesn't support rich dependencies.
But I don't know how to do it for EPEL 7/8, because the above file doesn't work. It ends with error [2]: error: Couldn't exec perl-libs: No such file or directory
Do you have any idea if there is any other way how to provide maintainers this functionality for EPEL 7/8?
Parametric macro dependency generators are not supported in EPEL 7 and 8's RPM versions. You can still implement this using a "regular" dependency generator. This is also described in the RPM documentation[1]. Instead of specifying %__perlcompat_requires() and writing an RPM macro that accepts a path name as %1, you specify `%__percompat_requires /path/to/executable`. That script receives a newline separated list of paths as stdin and prints the generated dependencies to stdout separated by newlines.
So perlcompat.attr could look something like
%__perlcompat_requires %{_rpmconfigdir}/perlcompat.req %{perl_version} # %%__perlcompat_path can stay the same.These are usually stored in %%{_rpmconfigdir}. %%{perl_version} is passed to the script as an argument, because the script of course doesn't have access to the RPM context. This can be any executable written in any language, but it should be straightforward to do this in shell.
-- Maxwell G (@gotmax23) Pronouns: He/Him/His _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Jitka Plesnikova Senior Software Engineer Red Hat _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
epel-devel@lists.fedoraproject.org
-
Jitka Plesnikova -
Kevin Fenzi -
Maxwell G -
Miro Hrončok