On 30. 11. 22 17:40, Jitka Plesnikova wrote:
MODULE_COMPAT is used for 1) Perl Modules and also 2) for packages which use
perl interpreter or libperl.so.
For the second case, the RPM dependency generator above does not work. These
packages may not contain
the Perl directories.
For now, I prefer to use the change describe in the proposal. It works for
all these cases.
Thanks for looking into it. I am not surprised that an RPM generator I
written in an email does not work out of the box for all the packages. It can
be enhanced. Do you have a specific example I can have a look at? Don't
packages using libperl.so already require a pretty specific soname version?
Do you think that saying something like this is generally a bad idea?
"""
Packages with Perl modules installed in %{perl_vendorlib} or
%{perl_vendorarch} will automatically gain dependency on perl-libs for pure
Perl modules or a dependency on perl(:MODULE_COMPAT_<perl_version>) for
libraries with compiled code.
Packages that require the Perl interpreter or libperl.so but do not install
modules to the aforementioned directories or explicitly link to
libperl.so.<perl_version> need to handle the dependency manually.
"""
To me, this still sounds like a massive improvement over both the status quo
and %perl_require_compat.
The dependency generator for this case should be following:
cat perlcompat.attr
%__perlcompat_requires() %{lua:
if macros[1]:match('.+%.so$') and macros.perl_version then
print('perl(:MODULE_COMPAT_' .. macros.perl_version .. ')')
else
print('perl-libs')
end
}
%__perlcompat_path
^(%{perl_vendorarch}|%{perl_vendorlib}|%{perl_privlib}|%{perl_archlib})/.+
Should be the file add to perl-generators or perl-srpm-macros?
I'd say perl-generators considering %{perl_vendorarch} etc. is not even defined
in the default buildroot where perl-srpm-macros is intalled.
The file attributes rules are applied on each file separately, if I understand
it correctly.
It means that perl-libs and MODULE_COMPAT will be added for Perl modules with
compiled code,
because there are not only *.so files.
Correct. In theory, a global Lua table can be used to cache the results based
on %{name} and refuse to generate perl-libs dependency if the
perl(:MODULE_COMPAT_...) one was already generated but I don't think it would
work when the files appear in an unfortunate order. Also, probably not worth-it.
Is it acceptable to have both dependencies for these packages?
I don't see why not, they will both evaluate to the same package, so it should
not matter.
The list of the packages which use MODULE_COMPAT and do not contain Perl
directories are here [1].
[1] https://jplesnik.fedorapeople.org/perl-module-compat/only-compat-no-dirs
Thanks, I will have a look.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
