The net-snmp-perl package depends on net-snmp-devel (from BZ 1134475 and 1438875), but as noted in BZ 1486733 this is overkill and pulls in a lot of unneeded dependencies (including gcc as a weak dep). It appears that this still is just for the command net-snmp-config, called from /usr/lib64/perl5/vendor_perl/Bundle/MakefileSubs.pm to get things that are known at RPM build time (CFLAGS and LDFLAGS). The requirement for net-snmp-config in /usr/bin/net-snmp-cert is already patched out and the RPM dependency was dropped, but then the dependency was re-added, from the spec changelog: * Mon Feb 17 2020 Josef Ridky <jridky> - 1:5.8-16 - set net-snmp-devel as requirement for net-snmp-perl It would be nice to get net-snmp-perl back to NOT depending on net-snmp-devel (and pulling in a bunch of development environment packages that aren't needed to just use e.g. the perl SNMP and/or NetSNMP modules). And maybe include a spec comment in the perl subpackage section that says "don't re-add Requires: net-snmp-devel").
It's pretty much the same situation with net-snmp-gui. Among other dependencies that seem reasonable, it pulls in net-snmp-devel, lm_sensors-devel, popt-devel and rpm-devel. I don't think this warrants a separate bug, it's the same packaging issue with a different subpackage.
net-snmp-gui is just an inheritor of the issue with net-snmp-perl, because net-snmp-gui Requires:net-snmp-perl (which is correct, since it's a perl script). The patch from BZ 1134475, net-snmp-5.7.2-cert-path.patch, starts with the comment: Use hardcoded path to configuration directories instead of net-snmp-config. net-snmp-config is in net-snmp-devel package and we do not want net-snmp-perl depending on -devel. But then the dependency was added back later with no comment other than that it was done. Arguably, if it's going to be required anyway, then this patch might as well be dropped. It looks pretty straight-forward to remove the net-snmp-config use from the perl module, but then... for some reason, mib2c is lumped into the net-snmp-perl package rather than net-snmp-devel or even a new net-snmp-mib2c package. Just because mib2c is written in perl doesn't mean it should be in the net-snmp-perl package (see for example net-snmp-gui already being split). The net-snmp-perl package should provide the perl module, not just be a grab-bag of some (but not all) perl-related things in net-snmp.
It's not just mib2c in the -perl package, it's really a grab-bag of "things using perl (except for gui)", so instead I took the approach of splitting the perl module itself off into another subpackage, -perl-module, and then patching perl/MakefileSubs.pm to get updated by configure with the flags rather than getting them from calling net-snmp-config.
Created attachment 1945354 [details] spec file patch to split perl module to subpackage and not require net-snmp-config Move the perl module itself to net-snmp-perl-module, and patch it to not require calling out to net-snmp-config, to reduce dependencies for things that just want perl(SNMP).
Created attachment 1945355 [details] Patch perl/MakefileSubs.pm so configure will update it Patch perl/MakefileSubs.pm so configure can update it with the appropriate flags at build time, rather than calling out to net-snmp-config at runtime. After patching, rename to perl/MakefileSubs.pm.in (done in suggested spec file patch).
https://src.fedoraproject.org/rpms/net-snmp/pull-request/6
I updated the pull request to delete MakefileSubs.pm rather than try to patch it, as it shouldn't even be installed anyway (it's only used during "perl Makefile.PL" step). I still think the perl module itself should be in a stand-alone RPM, because "I want perl programs to be able to do SNMP" doesn't mean "I want a bunch of random net-snmp tools that happen to use perl", which also then fixes the dependency problem. Any thoughts on this path?
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This is still a problem in Fedora 38 (and RHEL 8 and 9 for that matter), with an easy way to address it provided.
FEDORA-2023-fc7810d104 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-fc7810d104
FEDORA-2023-fc53b57ad3 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-fc53b57ad3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fc53b57ad3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-fc7810d104 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-fc7810d104` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fc7810d104 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-f1f1df110e has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-f1f1df110e
FEDORA-2023-ed5730ba26 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed5730ba26
FEDORA-2023-f1f1df110e has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-f1f1df110e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-f1f1df110e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ed5730ba26 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ed5730ba26` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed5730ba26 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This looks good - thanks!
FEDORA-2023-ed5730ba26 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-f1f1df110e has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.