As promised in <https://bugzilla.redhat.com/show_bug.cgi?id=1744676> and on #fedora-perl FreeNode channel, here are some information about packaging Perl code in for EPEL 8. EPEL 8.0 release was announced <https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/HXFHAPXPG2FX4NHP2WDNE3J3JXE53LML/>. We can start packaging Perl packages that do not exist in any RHEL repository. RHEL 8 has three repositories: BaseOS, AppStream, CodeReady Builder. While the first two are usually enabled, the third one is not enabled by default. So don't forget to search all of them before requesting an epel8 branch. RHEL 8 introduced modules. This is the user-facing part of Modularity you can know from Fedora <https://docs.fedoraproject.org/en-US/modularity/>. In RHEL-8.0, there is one perl module with two streams: perl:5.26 [d] perl:5.24 perl:5.26 is default and that means that by default the Perl visible to YUM is Perl 5.26. There are few other Modularity modules that provide RPM packages that package some Perl modules from CPAN. This is the complete list: perl-App-cpanminus:1.7044 [d] perl-DBD-MySQL:4.046 [d] perl-DBD-Pg:3.7 [d] perl-DBD-SQLite:1.58 [d] perl-DBI:1.641 [d] perl-FCGI:0.78 [d] perl-YAML:1.24 [d] Each of those modules have only one stream (i.e. one version of the software). Modularity allows you to select a different stream and that makes available a different set of packages. See <https://developers.redhat.com/blog/2019/05/16/modular-perl-in-red-hat-enterprise-linux-8/> for a tutorial how to work with streams in YUM. But there are plenty of other Perl packages in RHEL 8. These packages have not been modularized and thus they exist out of the modules and thus they are built and compatible only with the default perl stream, perl:5.26. Example is perl-libwww-perl. When it comes to adding packages or modules into EPEL, the situation is like this: If you add a normal non-modular package into EPEL, it will be built for Perl 5.26. Koji knows what streams are default and packages of those streams are added into Koji build root. Therefore Koji knows only perl-5.26.3 package, installs it when build-requiring perl-interpreter and your resulting packages will run-require perl(:MODULE_COMPAT_5.26.3). If you are fine with it just go and get packaging. If you want to add a new package into EPEL and build it as a module in order to support all Perls, you are out of luck. For now. EPEL 8 does not yet support building Modularity modules. The announcement promised this will be fixed around RHEL-8.1 release. Theoretical procedure is following: You will request creating a new repository in "modules" name space, you will request creating a new branch in that repository, you will import a modulemd file (something like a spec file, but this is for modules) into the the branch. If your modulemd refers to a new package, you will request creating a repository for the new package in "rpms" namespace. If you need a special branch for the package sources, you will request for the new branch. Then make sure your modulemd file build- and run-require "perl:[]" (the empty list in the brackets denotes all available streams of perl module). Then build the module using "fedpkg module-build". As a result, you will have two module builds (one for 5.24 and one for 5.26). Then you pass the builds to Bodhi to get them into EPEL repozitory. If you want to have the module content available by default (i.e. without a user enabling a specific stream of your module), you need to file a pull-request to a special rel-eng repository at pagure.io (<https://pagure.io/releng/fedora-module-defaults> for Fedora) to make the stream default. If you want to add a new stream of an existing module into EPEL, the procedure is the same, except you will probably won't be allowed to make the new stream default. If you want to make an existing non-modular RHEL package compatible for other Perls, you basically need to add a new module that will contain the package whose sources you copy from CentOS and then you build the module. The issue is that you will also get a build for Perl 5.26. This does not matter until you try to make your stream a default one. That would shadow the RHEL package for everybody and that probably won't be allowed. (If you noticed I wrote "probably", it's because I'm not sure about how the rules for "not replacing RHEL content" will look like in case of modules. I raised some question on EPEL list <https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/O3FULYWR4REM2GR4HQ6LEYBHKVBCCEYT/>.) Maybe you don't need to make the stream default. However, that has the drawback that people won't be able to do "yum install perl-Foo". They will have to do "yum module enable perl-Foo:bar" first. An obvious fix would be to disable building for Perl 5.26 by changing the modular dependency to "perl:[-5.26]". But if you do that YUM will complain that your module is incompatible with perl:5.26 (becuase it's default). All people will see that terrible warning until DNF changes behavior <https://bugzilla.redhat.com/show_bug.cgi?id=1717117>. Disabling building for a stream would also hinder all other modules built on top of your module. They would also be automatically stripped from the Perl 5.26 support. Imaging you want to package a completely new module to be of course available for the default Perl, but you cannot because some intermediary dependency is not available for that perl stream. This itself could be worked around by specifing a tree of modular dependendices <https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L97> where one subtree would be with perl:5.26 but without the offending module. But in my opinion that would become non-maintainable at large scale (at depth of a dependency tree). However, I believe there is a solution. It's a some sort of a hack that Red Hat already used when creating perl:5.26 stream. If you explored that stream thoroughly, you could notice the stream is empty. All it's packages are non-modular. This is technically in line with Modularity specification. We can use something similar. But this time not on the stream level, but on a context level. (Context is a word from modularity and it denotes a module stream built on a specific set of modules. E.g. perl-DBI:1.641 stream is only one, yet it exists in two contexts. One is built for perl:5.24, another one for perl:5.26. YUM automatically chooses the right context, so it's usually not presented to the users. An exceptition is "yum module info perl-DBI" command.) My vision for modularizing packages that exist as non-modular in RHEL: Create a new module a stream. Let the modulemd depend on all perl stream, including 5.26. Copy the package sources from CentOS, but modify the spec file in a way that if the package is being built with Perl 5.26, do not produce any binary package. Otherwise behave as usual. This will built your module for all Perls, but the 5.26 context will have no packages. Then put the module stream into YUM repozitory and make it default. If a user uses the default perl:5.26, installing the package will take it from RHEL. If a user has enabled perl:5.24, YUM will take the package from EPEL. That's because modular packages are preferred over non-modular packages. This only issue is that rpmbuild cannot build a package that produces no binary packages. A bandage fix is produce a dummy specially named binary package in case of Perl 5.26 and let modulemd to filter out the binary package. modulemd can exclude built binary packages from the resulting module build. And if the resulting binary package does not exist (in case of perl:5.24), it does not cause any error. Here is a pseudo code: perl-Foo.spec: Name: Foo %package -n dummy %if 0%(perl -e 'print $^V =~ m/^v5\.26\./') %file -n dummy %else %file %{perl_vendorlib}/... %endif perl-Foo.yaml: data: filter: rpms: - dummy components: rpms: - perl-Foo I'm sorry for the lengthy and boring e-mail. Once EPEL enables building modules, I'll test my ideas and write here whether it's doable. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-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/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
