[slurm-users] SLES 15 rpmbuild from 20.02.5 tarball wants munge-libs: system munge RPMs don't provide it

[Michael Jennings]

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 <mej at 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