On Tuesday, 20 October 2020, at 15:49:25 (+0800), Kevin Buckley wrote: > On 2020/10/20 11:50, Christopher Samuel wrote: > > > > I forgot I do have access to a SLES15 SP1 system, that has: > > > > # rpm -q libmunge2 --provides > > libmunge.so.2()(64bit) > > libmunge2 = 0.5.14-4.9.1 > > libmunge2(x86-64) = 0.5.14-4.9.1 > > munge-libs = 0.5.14 > > > > # rpm -q libmunge2 > > libmunge2-0.5.14-4.9.1.x86_64 > > > > So that _looks_ like it should satisfy the dependency. Is the > > --provides different for your SLES provided RPM? > > Yes. > > The ISOs I had access to from our build server - so some combo of > these (and probably the last of the four for anything munge): > > SLE-15-Installer-DVD-x86_64-GM-DVD1.iso > SLE-15-SP1-Installer-DVD-x86_64-QU2-DVD1.iso > SLE-15-SP1-Installer-DVD-x86_64-QU2-DVD2.iso > SLE-15-SP1-Packages-x86_64-QU2-DVD1.iso > > only have, as listed before, Munge 0.5.13. > > But again, your SLES15 SP1 munge RPMs *won't* have been built > directly from the source tarball (rpmbuild -ta) because the > SPEC file inside it is, according to Chris Dunlap, for systemd > CentOS & Fedora environments, though he packages an extra (non > default) one for SysV CentOS (read 6.x). > > Your SLES15 SP1 munge RPMs will have been built from the tarball, > buat against the SUSE-maintained SPEC file (rpmbuild -ba) and/or > a tarball at SUSE that's had their SPEC file "promoted" into the > top-level directory
So keep in mind a couple items: First and foremost, it's become increasingly challenging (read "almost impossible") to create RPM specfiles that will successfully build, install, and function correctly across all RPM-based platforms. Hell, even keeping specfile portability across RHEL/CentOS 6, 7, and 8 has proved challenging enough! Once you add Fedora (all "current" versions), then SuSE (SLES, OpenSuSE, Ports, Leap, ...), then Mandriva, then Mageia...they all have their own special "standards" for package naming, dependency handling, and so forth...all of which are mutually incompatible! It's a nightmare for anyone (like me, and Chris Dunlap, and SchedMD, and ...) who publishes software that they'd like to supply a specfile for, or anyone (like me, and Chris Samuel, and probably you!) who maintains customized versions of packages that must build, install, and function correctly on a range of RPM-based distributions and versions! But secondly, it's also useful to note that RPM's dependency engine does not give 2 hoots about which package "provides" a particular dependency that something else "requires;" it only cares that the graph is complete. So one thing I've done/recommended in the past is to create a ".nosrc.rpm" - i.e., an RPM that builds with a specfile but with no buildable source - that has "Requires:" entries to pull in the correct packages that you *wish* provided particular thing(s) and also contains one or more "Provides:" entries listing those same aforementioned thing(s). For example, a "munge-libs.spec" that contains both of the following lines should alleviate the issue: Requires: libmunge2 = 0.5.13-4.3.1 Provides: munge-libs = 0.5.13-4.3.1 In fact, you could probably even use %{expand: ...} and %(...) to dynamically set the <version>-<release> string based on "rpmquery" output, if you were so inclined. :-) You could, of course, simply maintain your own "munge" package and specfile that have all the right incantations in them, but this technique has the advantage of leaving the upstream vendor/distro packages and specfiles untouched, not to mention being easy to get rid of in the future if it's no longer needed. ;-) Michael -- Michael E. Jennings <m...@lanl.gov> - [PGPH: he/him/his/Mr] -- hpc.lanl.gov HPC Systems Engineer -- Platforms Team -- HPC Systems Group (HPC-SYS) Strategic Computing Complex, Bldg. 03-2327, Rm. 2341 W: +1 (505) 606-0605 Los Alamos National Laboratory, P.O. Box 1663, Los Alamos, NM 87545-0001