#2922 Issue closed: Missing RPM dependencies for "usual programs"¶
Labels: enhancement, no-issue-activity
schlomo opened issue at 2023-02-12 21:10:¶
Installing rear RPM from
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/openSUSE_Leap_15.3/x86_64/rear-2.7-1.x86_64.rpm
on openSUSE Leap 15.4 (don't we have a Leap 15.4 repo?)
leads to a broken installation because pidof is missing:
localhost:~ # cat /etc/os-release
NAME="openSUSE Leap"
VERSION="15.4"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.4"
PRETTY_NAME="openSUSE Leap 15.4"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.4"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"
LOGO="distributor-logo-Leap"
localhost:~ # rear --version
Relax-and-Recover 2.7 / 2022-07-13
localhost:~ # rear dump
ERROR: Cannot find required programs: pidof
Some messages from /var/tmp/rear.jJqPVr6xw65nt5h/tmp/rear.dump.stdout_stderr since the last called script 950_check_missing_programs.sh:
/usr/share/rear/lib/_input-output-functions.sh: line 525: type: pidof: not found
/usr/share/rear/lib/_input-output-functions.sh: line 525: type: pidof: not found
Use debug mode '-d' for some debug messages or debugscript mode '-D' for full debug messages with 'set -x' output
Aborting due to an error, check /var/log/rear/rear-localhost.log.lockless for details
Terminated
Installing the sysvinit-tools seems to fix this problem.
@jsmeix can we just add that dependency
or will this create a problem on other distros?
jsmeix commented at 2023-02-13 13:20:¶
It is not a 'bug' in a program when the program aborts
with a meaningful error message when it cannot continue
because then the issue is properly handled in the program
(which does not mean the software cannot be 'enhanced' to
deal better with the underlying root cause - if possible).
In this case it is handled in
init/default/950_check_missing_programs.sh
cf.
https://github.com/rear/rear/issues/892
Because noone else reported this issue up to now,
it seems 'pidof' is normally installed on Linux distributions.
In general we do not have explicit RPM dependencies
for every program that is usually called in ReaR.
We have only few RPM dependencies in rear.spec
https://github.com/rear/rear/blob/master/packaging/rpm/rear.spec
In general we assume that "standard programs" are there.
On my openSUSE Leap 15.4 homeoffice system (with Gnome desktop)
'sysvinit-tools' is a required RPM package
# rpm -e --test sysvinit-tools
error: Failed dependencies:
sysvinit-tools is needed by (installed) insserv-compat-0.1-4.6.1.noarch
sysvinit-tools is needed by (installed) openvpn-2.5.6-150400.3.3.1.x86_64
/sbin/pidof is needed by (installed) xdm-1.1.11-150400.23.6.x86_64
so it seems your openSUSE Leap 15.4 installation
is a very minimal (perhaps even a too minimal) installation?
For my tests on VMs I use small systems without desktop
and I never had the issue that 'pidof' was missing.
But what I always do is to let the "recommended" packages
be installed - i.e. what is specified in a spec file as
Recommends: RPM_capability
because that avoids to get a system where things are missing
that are "usually just there", e.g. on my Leap 15.4 system
# rpm -e --test vim
[no output]
'vi' is not required but nevertheless it is "just there".
In general:
All explicit RPM dependencies are always a problem because
every explicit RPM dependency requires manual maintenance
which is likely different for different Linux distributions.
Explicit RPM requirements cause trouble in particular because
when one cannot be fulfilled the package cannot be installed and
when one is missing the software in the package doesn't work and
when one is not a real hard requirement some users complain
that they cannot use the software in a minimal system and so on...
Offhandedly I don't know to generically specify in RPM
that a program called 'pidof' is required.
I guess
Requires: pidof
won't work because (on my Leap 15.4 system)
# rpm -q --whatprovides pidof
no package provides pidof
# rpm -q --whatprovides bin/pidof
no package provides bin/pidof
# rpm -q --whatprovides /bin/pidof
sysvinit-tools-2.99-1.1.x86_64
so it seems I have to specify the program with full path
but what /path/pidof is generic for all RPM based distributions?
# type -a pidof
pidof is /sbin/pidof
pidof is /bin/pidof
# file /sbin/pidof /bin/pidof
/sbin/pidof: symbolic link to killall5
/bin/pidof: symbolic link to /sbin/killall5
As time permits I will try to find out
if it is possible to generically specify in RPM
that a program called 'sometool' is required.
When this is possible (also for older RPM based distributions)
we can add all REQUIRED_PROGS as such generic RPM 'Requires'
and all in PROGS as such generic RPM 'Recommends'.
jsmeix commented at 2023-02-13 13:32:¶
Regarding "a Leap 15.4 repo" see
https://github.com/rear/rear/issues/2890#issuecomment-1323462648
# osc results -v Archiving:Backup:Rear rear-2.7 | grep '15\.'
openSUSE_Leap_15.3 x86_64 succeeded
openSUSE_Leap_15.3 ppc64le succeeded
15.4 x86_64 succeeded
15.4 ppc64le succeeded
# osc results -v Archiving rear | grep '15\.'
openSUSE_Leap_15.4 x86_64 succeeded
openSUSE_Leap_15.4 ppc64le succeeded
The repository naming in OBS looks inconsistent.
Perhaps there is some technical reason behind
but this is in areas that I don't understand.
schlomo commented at 2023-02-13 13:45:¶
About the distro RPM repos, maybe all we need to do is update the list at https://relax-and-recover.org/download/
I was using a Leap 15.4 "Minimal Server" installation to reduce the size of the ReaR backup during testing. I'd suggest to always use the distro minimal software selection for validation as that will help us to ensure that ReaR will work on all "normal" installs, meaning installations that use the distro installer with its default settings.
The reason I wanted to talk about this package - and I think this issue
should really only be about pidof and not about everything, is that it
seems like different RPM distros use different package names:
https://rpmfind.net/linux/rpm2html/search.php?query=sysvinit-tools
is for SUSE and CentOS 7 only
https://rpmfind.net/linux/rpm2html/search.php?query=procps-ng
is for CentOS 8+, Fedora and others
Given that, can we now add it to our rear.spec and the respective
distro specific spec files? Given the fact that ReaR won't work without
pidof I'd think that this could be reason enough to make it a hard RPM
dependency.
I fully agree with you that we shouldn't have RPM/DEB dependencies on optional ReaR functionality.
jsmeix commented at 2023-02-13 14:19:¶
Regarding
https://relax-and-recover.org/download/
see
https://github.com/rear/rear.github.com/pull/16
Regarding RPM requirements:
Let me find out if it is possible to generically specify in RPM
that a program called 'sometool' is required.
I don't want to manually maintain individual RPM requirements
for RPM package names or specific RPM capabilities that
are likely different for different Linux distributions
simply because I don't get paid for that (no SUSE customer
ever reported an issue about that to me - I guess they help
themselves when they use minimal systems - or perhaps
SUSE support helps them and I won't notice that).
In the future RPM and such will go away anyway and
we all will be happy in total containerized isolation ;-)
schlomo commented at 2023-02-17 08:15:¶
I had a bit more thought about this:
In the end, I'd like us to get to the point where a "zypper install URL-TO-REAR-RPM" would lead to a ReaR installation that works. That means that whatever programs are required for ReaR to run with the included default configuration must be covered by the RPM dependencies.
Same for the YUM and DEB ecosystems, of course.
And for that minimum requirements I don't want to rely on package manager recommendations as we talk about the minimum required programs for ReaR to run without an error. The motivation for investing our efforts into this would be to give users a successful out-of-the-box experience, where they install ReaR and try it out and then it must work and not fail on a missing program.
But indeed this is only about the bare minimum for the default config and I agree with you that users need to add required programs themselves to cover their configuration changes, e.g. adding Rsync if they want to do a backup via Rsync.
jsmeix commented at 2023-02-17 08:57:¶
ReaR never gave users a successful out-of-the-box experience.
My first trial with ReaR was a complete abysmal disaster.
I never had a worse first impression with a program.
Meanwhile ReaR works somewhat "sufficiently OK"
for experienced users (in particular system admins)
who know what they do and what "disaster recovery" means.
A successful out-of-the-box user experience is far away,
cf.
https://github.com/rear/rear/wiki/Developers-Guide
Feel free to implement that - I do fully appreciate it.
But I won't help because I don't get paid for that.
schlomo commented at 2023-02-17 09:46:¶
OK, fair enough. Is packaging/rpm/rear.spec still used to generate the
SUSE RPMs? Or do we have a different spec file in OBS? I don't mind
adding that dependency.
github-actions commented at 2023-04-19 02:22:¶
Stale issue message
[Export of Github issue for rear/rear.]