#369 Issue closed: Replace "lsb" RPM requirement in "rear" RPM for openSUSE

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2014-02-18 16:19:

In contrast to RHEL6 where only redhat-lsb-core is needed, openSUSE has not yet split its "lsb" package into sub-packages, see https://bugzilla.novell.com/show_bug.cgi?id=862824

Until that happened the RPM requirement for "lsb" requires much too much for rear because since openSUSE 13.1 the lsb package requires various graphical libraries, sound stuff, printing stuff, and so on, see https://bugzilla.novell.com/show_bug.cgi?id=807747

Therefore since openSUSE 13.1 the RPM requirement for "lsb" in rear.spec should be replaced with a list of explicit packages that are actually needed by rear.

I did that for rear in its openSUSE build service development project "Archiving", see the rear.spec file at


for an initial proposal how that might be done.

jsmeix commented at 2014-02-19 15:07:

By chance I noticed
"redhat-lsb-core pulls in the graphical stack due to cups"

To ensure a rear RPM can be installed without issues even on a minimal (server) system, rear might in general no longer require lsb packages but require explicitly only those packages (or executables) that are actually needed by rear.

gdha commented at 2014-03-03 07:51:

@jsmeix list the individual packages might become a nightmare to maintain across all the different platforms and Linux distro's we're supporting. The lsb package was meant to deal with this. I never understood why it exploded in size the way it did? A standard way of working (around lsb) across all Linux distro's seems to me the proper way to go.

jsmeix commented at 2014-03-12 15:22:

The SUSE lsb package requirements "exploded" because of https://bugzilla.novell.com/show_bug.cgi?id=807747 see in particular what Robert Schweikert wrote in https://bugzilla.novell.com/show_bug.cgi?id=807747#c4 and his original mail at

In short: A Linux distribution cannot be partially LSB compliant. In contrast a particular installed system can.

Currently our lsb package requires the full LSB stuff. It is it is not yet split into sub-packages, see https://bugzilla.novell.com/show_bug.cgi?id=862824 so that requiring the lsb package requires all LSB stuff.

As long as our lsb package is not split into sub-packages Relax-and-Recover should not require it.

When our lsb package is split into sub-packages Relax-and-Recover may require an appropriate sub-package like lsb-core (or whatever it might be called).

Alternatively a more generic way could be when Relax-and-Recover requires no lsb-* packages but the files (in particular the executables) that are actally needed by Relax-and-Recover. For example our lsb package has this kind of requirements, see its current spec file at https://build.opensuse.org/package/show/Base:System/lsb

gdha commented at 2014-08-22 14:39:

If we would remove in our spec file the following:

%if %{!?sles_version:1}0
Requires: lsb

We could replace it with a prep script to investigate if we have all the required binaries with a script similar to prep/default/95_check_missing_programs.sh (but perhaps specific for SLES)?

gdha commented at 2015-05-15 19:36:

@jsmeix could you list the packages SLES need at minimum? This is not an urgent request - take your time.

jsmeix commented at 2015-05-18 08:20:

I think in practice it is impossible to specify what SLES packages are needed by rear at minimum. The problem is what "at minimum" means.
I have no idea how I could determine that. I think it depends on run-time on a particular end-user's system what exact code paths in the rear bash scripts are executed which determines what exact programs are actually called which results what exact software packages are needed on a particular end-user's system.

What I did instead some time ago was a simple analysis what programs are called by the rear bash scripts. I described what I did in the rear.spec file of the source package rear in the openSUSE build service project "Archiving" (which is the development project for rear in openSUSE:Factory), see:



# LSB RPM Requires:
# Begin of "Requires: lsb" cleanup:
# Rear upstream has "Requires: lsb" but that requires much too much,
# see https://bugzilla.novell.com/show_bug.cgi?id=807747#c4
# "A distribution is LSB Certified or LSB compliant if and only if
#  the distribution provides all requirements as outlined in the
#  specification."
# Accordingly SUSE's lsb RPM requires tons of stuff that is not
# needed by Rear (in particular various graphical libraries,
# sound stuff, printing stuff, and so on).
# Therefore "Requires: lsb" is replaced by explicitly listing the RPM packages
# that are mandatory (in particular when a binary is called in a script) for Rear (as RPM Requires)
# plus what seems to be optional (nice to have) for Rear (as RPM Recommends)
# minus library packages because needed libraries should be automatically required.
# I <jsmeix@suse.de> think requiring RPM packages instead of binaries is better
# because it keeps the list shorter which is hopefully easier to maintain and
# the requirements are on a more higher level which is hopefully more unsusceptible against
# minor changes in what exact binaries names are actually called by Rear.
# To test if a binary is called by a Rear script the following was done (example for /usr/bin/bc):
#   BIN="bc"
#   for f in $( find /usr/share/rear/ )
#   do grep "\<$BIN\> " $f 2>/dev/null | grep -v '^[[:space:]]*#'
#   done
# What is not tested to find out if a binary is called by a Rear script is "eval" stuff,
# something like STRING=<result of whatever calls> ; eval $STRING
# Usually Rear calls "eval echo ..." or "eval "${EXTERNAL_whatever[@]}"
# except in /usr/share/rear/finalize/default/88_check_for_mount_by_id.sh that calls
#   eval "$(scsi_id ...
# where the only scsi_id that I could find is /usr/lib/udev/scsi_id
# which belongs to udev and I assume that udev is installed in any case
# so that there is no explicit RPM Requires for udev in Rear.
# What is also not tested to find out what Rear actually needs is
# which files (not only binaries) Rear needs to build up its recovery system
# (in particular tools for partitioning, creating filesystems, and bootloader installation).
# I assume what Rear needs to build up the system-specific recovery system is installed
# (e.g. if the ext4 filesystem is used, I assume mkfs.ext4 is installed)
# so that there are no explicit RPM Requires needed for that in Rear.
# The following list was derived from the RPM Requires of SUSE's lsb package
# (its last RPM changelog entry dated "Tue Oct  1 07:01:56 UTC 2013") as follows:
#   for r in $( grep ^Requires: lsb.spec | tr -s ' ' | cut -d ' ' -f2 )
#   do rpm -q --whatprovides $r
#   done | sort -u 
# which results the following list where only what is needed for Rear is activated:
#   Mesa-9.2.3-61.9.1.i586
#   Mesa-libGL1-9.2.3-61.9.1.i586
#   at-3.1.13-5.4.1.i586
Requires:       bash
Requires:       bc
Requires:       binutils
Requires:       coreutils
Requires:       cpio
#   cronie-1.4.8-50.1.2.i586
#   cups-client-1.5.4-140.1.i586
Requires:       diffutils
#   ed-1.9-2.1.2.i586
Requires:       file
Requires:       findutils
#   fontconfig-2.11.0-1.1.i586
#   foomatic-filters-4.0.12-5.1.1.i586
Requires:       gawk
#   gettext-runtime-
#   ghostscript-9.10-45.4.i586
# Rear calls getent in /usr/share/rear/rescue/default/90_clone_users_and_groups.sh
Requires:       glibc
#   glibc-i18ndata-2.18-4.11.1.noarch
Requires:       grep
Requires:       gzip
#   libGLU1-9.0.0-7.1.2.i586
#   libXt6-1.1.4-2.1.2.i586
#   libXtst6-1.2.2-2.1.2.i586
#   libasound2-
#   libatk-1_0-0-2.10.0-1.1.i586
#   libglib-2_0-0-2.38.2-8.2.i586
#   libgtk-2_0-0-2.24.22-2.1.i586
#   libjpeg62-62.0.0-24.1.3.i586
#   libpango-1_0-0-1.36.1-4.2.i586
#   libpng12-0-1.2.50-6.1.2.i586
#   libqt4-4.8.5-5.6.1.i586
#   libqt4-sql-4.8.5-5.6.1.i586
#   libqt4-x11-4.8.5-5.6.1.i586
#   libxml2-tools-2.9.1-2.1.2.i586
# Rear calls "lsb_release" in /usr/share/rear/lib/config-functions.sh
Requires:       lsb-release
#   m4-1.4.16-14.1.2.i586
#   mailx-12.5-14.1.3.i586
#   make-3.82-160.2.1.i586
#   man-2.6.3-9.1.3.i586
#   mozilla-nss-
Requires:       net-tools
#   patch-2.7.1-4.1.2.i586
#   pax-3.4-155.1.2.i586
Requires:       perl-base
#   postfix-2.9.6-7.4.1.i586
Requires:       procps
#   psmisc-22.20-5.1.2.i586
#   python-2.7.5-8.3.1.i586
#   python3-3.3.2-5.1.3.i586
#   qt3-3.3.8c-128.1.2.i586
Requires:       rsync
Requires:       sed
#   shadow-
#   systemd-sysvinit-208-15.1.i586
#   sysvinit-tools-2.88+-89.1.2.i586
Requires:       tar
#   time-1.7-3.1.2.i586
Requires:       util-linux
#   xdg-utils-20121008-2.2.1.noarch
# End of "Requires: lsb" cleanup.
# Non-LSB RPM Requires:
# all RPM based systems seem to have this and call it the same
Requires:       ethtool
Requires:       iproute2
Requires:       iputils
%if 0%{?suse_version} >= 1230
Requires:       %{_sbindir}/agetty
Requires:       /sbin/mingetty
%if %{with use_mkisofs}
Requires:       %{_bindir}/mkisofs
Requires:       %{_bindir}/genisoimage
# recent SUSE versions have an extra nfs-client package
Requires:       nfs-client
# Rear calls openssl in /usr/share/rear/rescue/default/50_ssh.sh
Requires:       openssl
# openSUSE from 11.1 and SLES from 11 uses rpcbind instead of portmap
Requires:       rpcbind
Requires:       syslinux

That results the following RPM requirements

for SLES11

$ osc getbinaries Archiving rear SLE_11_SP3 x86_64
$ rpm -q --requires -p binaries/rear-1.17.0-47.2.noarch.rpm | sort

and for SLES12:

$ osc getbinaries Archiving rear SLE_12 x86_64
$ rpm -q --requires -p binaries/rear-1.17.0-47.2.noarch.rpm | sort

Note that in both cases e.g. dosfslabel (cf. https://github.com/rear/rear/issues/229) is not yet included because I did my analysis what programs are called by the rear bash scripts some time ago.

Other requirements are probably not mandatory (i.e. there are more than the minimal requirements listed above). For example I guess that rsync is not needed on all end-user's particular systems.

jsmeix commented at 2015-05-18 09:24:


Programs like dosfslabel are not required by rear because in my above analysis I only tested which of the programs that are required by our "lsb" package are actually called (i.e. needed) by rear.

What our "lsb" package requires is only what is called "lsb-core" by LSB.

Because programs like dosfslabel are not required by "lsb-core" those are not required by rear.

I think programs like dosfslabel should never be required by rear because in general RPM requirements should be only used for what is mandatory to run rear. Anything else should be specified by RPM "Recommends".


In general RPM requirements should be only used for essential stuff i.e. for what is mandatory to make it work. For anything else RPM recommends should be used. RPM Requires are hard dependencies that cannot be skipped by admins (without having unresolved dependencies in their systems).

Furthermore: If I remember correctly the openSUSE build service installs all RPM Requires to set up the build system of a package so that all RPM Requires in a package result that all those hard dependencies must be installed in our build systems for any other package that directly or indirectly BuildRequires the package.

In short:

We should keep RPM Requires as small as possible - i.e. only what is really mandatory - and specify all what is optional (i.e. what is not really mandatory) as RPM Recommends.

Currently there are no RPM "Recommends" in the rear package. The main reason is that I don't know how to determine what should be recommended by rear.

gdha commented at 2015-11-01 09:52:

@jsmeix I think mandatory programs should be added to the REQUIRED_PROGS array. This way, when not available rear will stop with an error. I have done this lately for EFI with dosfstools as an example. We should use the prep work-flow in a better way - trying to correct this step-by-step (when I come across a current situation).

@jsmeix @schlomo @jhoekx @dagwieers
In packaging we still found some references to lsb-release:

./packaging/arch/PKGBUILD:depends=(lsb-release iproute2 parted cpio openssl gawk)
./packaging/arch/PKGBUILD.local:depends=(lsb-release iproute2 parted cpio openssl gawk)
./packaging/debian/control:Depends: syslinux, ethtool, ${shlibs:Depends}, lsb-release, portmap, genisoimage, iproute, iputils-ping, binutils, parted, openssl, gawk, attr, ${misc:Depends}
./packaging/gentoo/rear.ebuild: sys-apps/lsb-release

Shouldn't we remove these as well?

schlomo commented at 2015-11-01 10:18:

I am fine with removing the lsb-release requirement. Just keep in mind the consequences:

  • We need to add much more stuff to REQUIRED_PROGS
  • We need to be able to detect OS_VENDOR and OS_VERSION without lsb_release

I would actually remove the dependency only after we don't need the lsb_release tool any more.

jsmeix commented at 2015-11-02 10:42:

I fully agree with @gdha to move the requirements
from the RPM spec file into the actual rear code.

Only an untested idea how to detect OS_VENDOR and OS_VERSION
nowadays (i.e. it does not work for older distributions):

Using /etc/os-release



root@sles12# cat /etc/os-release
PRETTY_NAME="SUSE Linux Enterprise Server 12"
root@sles12sp1# cat /etc/os-release
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP1"
root@openSUSE13.2 # cat /etc/os-release
VERSION="13.2 (Harlequin)"
PRETTY_NAME="openSUSE 13.2 (Harlequin) (x86_64)"

schlomo commented at 2015-11-02 20:21:

Yes, /etc/os-releasehas the same info. What about pre-systemd distros? Do we drop support for those?

gdha commented at 2015-12-20 09:09:

See also the discussion of related issue #731 - it is about the same. The main problem is the detection of older Debian related distr.'s (without lsb_release). See also issue #696 and pull request discussion at https://github.com/rear/rear/commit/613ba6f379e0ad93e47f707f1ae351d781008732

gdha commented at 2016-02-02 16:46:

We better post-pone this to 1.19 as os-release detection is not yet fully in place

jsmeix commented at 2016-09-21 13:04:

The current RPM requirements seem to be o.k.
at least for now because I don't know about
real issues because of that.

I will work on it as needed in the future.

jsmeix commented at 2016-09-28 13:54:

I like to close it because currently it is o.k.
and when later new issues appear
new GitHub issues should be submitted.

[Export of Github issue for rear/rear.]