#294 openldap build pull in the wrong perl module
Closed: Insufficient Data a month ago by arrfab. Opened 5 months ago by dcavalca.

We're trying to build openldap as part of the Hyperscale SIG (https://pagure.io/centos-sig-hyperscale/sig/issue/43 for context). We've branched and built this in https://cbs.centos.org/koji/buildinfo?buildID=32748 but that results in an uninstallable openldap-servers package due to:

[davide@localhost ~]$ sudo dnf install openldap-servers
Last metadata expiration check: 0:00:21 ago on Fri 16 Apr 2021 08:29:16 AM PDT.
Error: 
 Problem: package openldap-servers-2.4.46-16.hs.el8.x86_64 requires libperl.so.5.30()(64bit), but none of the providers can be installed
  - conflicting requests
  - package perl-libs-4:5.30.1-452.module_el8.4.0+646+45e06e4a.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[davide@localhost ~]$

After discussing this with @smooge on IRC, we've concluded that the issue here is that this build is somehow picking up the perl-5.30 module stream instead of perl-5.26. However, there doesn't seem a way to specify a dependency on perl-5.26 via BuildRequires. If this were mock, we could set config_opts['module_enable'] and config_opts['module_install'] but I don't think that's an option in CBS.

Could you please advise on the best course of action here? Thanks!


Extra context from IRC:

<ssmoogen[m]> dcavalca: so in RHEL-8 there is an empty module which has all 5.26 items in it
<dcavalca> ssmoogen[m]: I see, so I guess I need to find a way to make my package BR against it instead of the 5.30 it's somehow picking up
<ssmoogen[m]> I am trying to see what epel has in its breakup.. it is rather 'weird'
<ssmoogen[m]> ok yes.. there should be a perl-5.26 which needs to be enabled for your build. this should pull in the 'default' perl versus the 5.30
<ssmoogen[m]> 5.30 became the 'platform' default for 8.4
<ssmoogen[m]> if I am reading the foobar-modules.yaml.gz file even half-way correctly
<dcavalca> ssmoogen[m]: how do I add a buildrequires against that though? I tried both perl-5.26 and perl:5.26 and neither work
<ssmoogen[m]> well if this were a base mock config it would be adding config_opts['module_enable'] = ['list', 'of', 'modules'] config_opts['module_install'] = ['module1/profile', 'module2/profile'] versus a buildrequires.
<ssmoogen[m]> buildrequires doesn't know how to pull in modules as far as I can tell. mock does because it sets up the outer arguments.
<dcavalca> uh, I don't think I can do that in CBS
<ssmoogen[m]> for 'koji' type builds I have found that you either need to demodularize the buildroot or you need to make your software to compile a module.

@carlgeorge mentioned on IRC that epel uses grobisplitter to put default module streams into a build repo, so that might be an option here.

Metadata Update from @arrfab:
- Issue tagged with: cbs, need-more-info

5 months ago

Welcome to modularity ...
Building pkgs that consume pkgs from modules is difficult as depending on the {Build}Requires: chain, it can pick some pkgs from non default module.
Normally perl 5.26 is still marked as the default module if no module is specified

sudo dnf module list |grep perl
perl                 5.24             common [d], minimal                      Practical Extraction and Report Language                                                                                                                                                                                         
perl                 5.26 [d][e]      common [d], minimal                      Practical Extraction and Report Language                                                                                                                                                                                         
perl                 5.30             common [d], minimal                      Practical Extraction and Report Language          

Worth verifying if other pkgs that are required to build your pkg were built themselves as module and so requiring specific perl version/binding ?

Don't know grobisplitter (even if I heard of it for epel case) and don't know if module-build-service is to be considered for cbs.centos.org (but that would mean people building their pkgs as modules instead of normal pkgs).

Worth discussing when people will have time to investigate this.

Metadata Update from @arrfab:
- Issue tagged with: groomed

5 months ago

@dcavalca : any news on original request or can we close it ? (no feedback received from other people in the last months)

I think we can close this, now that EPEL is available we should be able to build this package there and sidestep the issue altogether.

Metadata Update from @arrfab:
- Issue close_status updated to: Insufficient Data
- Issue status updated to: Closed (was: Open)

a month ago

Login to comment on this ticket.

Metadata
Boards 1
CBS Status: Backlog