#165 What modular packages (build)require Python 2 on rawhide? Also, other queries.
Opened 4 years ago by churchyard. Modified 2 years ago

We have this approved system wide change for Fedora 32: https://fedoraproject.org/wiki/Changes/RetirePython2

I'd like to get list of modules that have packages (build)requiring Python 2, so I can contact their maintainers about this and work towards a solution that works for them.

I am only aware of the ReviewBoard + Django combo that uses Python 2.

I'd like to run the equivalent of this:

$ repoquery --repo=rawhide{,-source} --whatrequires python27

But for all modular content in Rawhide, default and non-default.

I've tried to use the modular-repoquery script provided by @asamalik but I probably don't know how to use it properly, as it gives the wrong results.

Could you please:

  1. help me determine the correct results?
  2. help me understand how you did 1.?
  3. possible make this simpler, if it turns out 1./2. are non-trivial?

Thanks.


One of the things to bear in mind is that not everything is in the repo. There exist modules that are "buildroot only" and also some modules filter out some artifacts that never get published.

In this cases I find it useful to make a local cache of the module directly from a koji tag.

I wrote this script:

https://github.com/mbooth101/modularity-misc/blob/master/cache_module.sh

That can be invoked with <module_name> <stream_name> <fedora_version> for example:

$ ./cache_module.sh maven 3.5 29
$ ./cache_module.sh javapackages-tools 201801 28

And this should download all binary RPMs for that module stream including for buildroot-only modules and including filtered RPMs.

Thanks for the script. I'd rather not download all the packages just to query them. That is a significant usability drawback. I would also need a way to get the proper arguments to the script.

Thanks for the script. I'd rather not download all the packages just to query them.

Me neither. If there is another way, I would love to know it :-)

I think this depends on #166 but also needs some more thoughts.

Metadata Update from @psabata:
- Issue tagged with: needs-design

4 years ago

I think this depends on #166

I don't understand why, could you please elaborate on that?

@dmach Has anything changed in this space in DNF 5? Can we repoquery for contents provided by non-enabled modules?

I think the main problem here is the inability to repoquery non-shipped items. You can repoquery non-default modules (e.g., RHEL 8): yum repoquery --setopt=*.module_hotfixes=yes --whatprovides 'bundled(tomcat)' to find the tomcat package that RHEL 8 "doesn't ship" but really does; but you can't use the same thing to find packages actually-not-shipped : yum repoquery --setopt=*.module_hotfixes=yes --whatprovides golang-github-cpuguy83-go-md2man returns no results.

@sgallagh we don't plan any changes to repoquery.
You can use dnf module provides <pkg> to search in all modules incl. inactive.

@cyberpear Thanks for the trick. It yields some data:

$ for provide in 'libpython2.7.so.1.0' 'libpython2.7.so.1.0()(64bit)' 'pkgconfig(python-2.7)' 'pkgconfig(python2)' 'python(abi) = 2.7' python2 python2-devel python2-tkinter python2.7 'python2.7(x86-64)' 'python2.7(x86-32)' python27; do repoquery --setopt=*.module_hotfixes=yes --repo=rawhide-modular{,-source} --whatrequires "$provide" 2>/dev/null; done | sort | uniq
antlr-0:2.7.7-56.module_f28+3872+5b76729e.src
nodejs-1:10.21.0-2.module_f33+9072+e49be65a.src
openmpi-0:3.1.6-1.module_f33+8674+f185d4cf.src
python2-antlr-0:2.7.7-56.module_f28+3872+5b76729e.noarch

How do I tell where does this come from?

Side note: The fc28 dist tags are not nice.

"dnf module provides" does not search in RPM Provides. It only searches in RPM package NEVRAs.

Current dnf-4.8.0-1.fc33 reports a module build the found package belongs to:

# dnf -q module provides perl-libs | head -n 15
perl-libs-4:5.30.3-454.module_f33+9369+dac0eadc.x86_64
Module   : perl:5.30:3320200819225620:394aad6b:x86_64
Profiles : 
Repo     : fedora-modular
Summary  : Practical Extraction and Report Language

perl-libs-4:5.30.3-454.module_f33+9711+083176da.x86_64
Module   : perl-bootstrap:5.30:3320200812210115:601d93de:x86_64
Profiles : 
Repo     : fedora-modular
Summary  : Perl bootstrap module for bootstrapping Perl module

perl-libs-4:5.30.3-454.module_f33+9711+083176da.x86_64
Module   : perl-bootstrap:5.30:3320200812210115:601d93de:x86_64
Profiles : 

I think it's too verbose for an ordinal user. Limiting the output to latest module versions should be enough. (--latest option?)

The option --latest can be implemented when static_context=true will be fully supported standard in Fedora and RHEL. Do we still release static_context=false to Fedora?

We still release stream-expanded contexs to Fedora because there is an MBS bug https://pagure.io/fm-orchestrator/issue/1714 preventing from using modulemd-packager-v3 format which produces static_context=true builds. The bug is resolved in an MBS upstream now and the build infrastructure should be hot-fixed in a few days. Then I will retry porting Perl modules and in case of success I will start a campaign for migrating all Fedora modules to static_context=true. Until then there will be static_context=false modules.

Log in to comment on this ticket.

Metadata