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
