#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
https://build.opensuse.org/package/view_file/Archiving/rear/rear.spec?expand=1
for an initial proposal how that might be done.
jsmeix commented at 2014-02-19 15:07:¶
By chance I noticed
https://bugzilla.redhat.com/show_bug.cgi?id=1002342
"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
http://lists.linuxfoundation.org/pipermail/lsb-discuss/2013-May/007643.html
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
%endif
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:
https://build.opensuse.org/package/view_file/Archiving/rear/rear.spec?expand=1
excerpt:
# 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-0.18.3.1-1.1.i586 # 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-1.0.27.2-3.5.1.i586 # 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-3.15.3.1-8.1.i586 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-4.1.5.1-8.1.2.i586 # 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 %else Requires: /sbin/mingetty %endif %if %{with use_mkisofs} Requires: %{_bindir}/mkisofs %else Requires: %{_bindir}/genisoimage %endif # 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 rear-1.17.0-47.2.noarch.rpm $ rpm -q --requires -p binaries/rear-1.17.0-47.2.noarch.rpm | sort bash bc /bin/bash binutils coreutils cpio diffutils ethtool file findutils gawk glibc grep gzip iproute2 iputils lsb-release net-tools nfs-client openssl perl-base procps rpcbind rsync /sbin/mingetty sed syslinux tar /usr/bin/mkisofs util-linux
and for SLES12:
$ osc getbinaries Archiving rear SLE_12 x86_64 rear-1.17.0-47.2.noarch.rpm $ rpm -q --requires -p binaries/rear-1.17.0-47.2.noarch.rpm | sort bash bc /bin/bash binutils coreutils cpio diffutils ethtool file findutils gawk glibc grep gzip iproute2 iputils lsb-release net-tools nfs-client openssl perl-base procps rpcbind rsync sed syslinux tar /usr/bin/mkisofs /usr/sbin/agetty util-linux
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:¶
Correction:
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".
Reasoning:
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.
Regarding OS_VENDOR and OS_VERSION:
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
Cf.
http://www.freedesktop.org/software/systemd/man/os-release.html
Examples:
root@sles12# cat /etc/os-release NAME="SLES" VERSION="12" VERSION_ID="12" PRETTY_NAME="SUSE Linux Enterprise Server 12" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12" root@sles12sp1# cat /etc/os-release NAME="SLES" VERSION="12-SP1" VERSION_ID="12.1" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP1" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp1" root@openSUSE13.2 # cat /etc/os-release NAME=openSUSE VERSION="13.2 (Harlequin)" VERSION_ID="13.2" PRETTY_NAME="openSUSE 13.2 (Harlequin) (x86_64)" ID=opensuse ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:opensuse:13.2" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://opensuse.org/" ID_LIKE="suse"
schlomo commented at 2015-11-02 20:21:¶
Yes, /etc/os-release
has 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.]