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

[Brian Andrus]

I concur with so much of this.

One thing I tend to do is just keep my own .spec file updated to build 
the various things I need done in a particular way (openmpi, slurm, etc)

When a source is updated, I update it as necessary, but at least I have 
a known process and environment for my packages. Source control for me 
is just that spec file.

Brian Andrus

On 10/20/2020 8:46 AM, Michael Jennings wrote:
> 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
>