#1855 Issue `closed`: Fedora rear.spec is violating Spec Maintenance and Canonicity¶

Labels: cleanup, fixed / solved / done

gdha opened issue at 2018-07-11 08:42:¶

ReaR version ("/usr/sbin/rear -V"): 2.4 and higher
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Fedora
ReaR configuration files ("cat /etc/rear/site.conf" or "cat /etc/rear/local.conf"): N/A
Brief description of the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1599924

https://src.fedoraproject.org/rpms/rear/c/1b0370180d627d4c63b51fac0f31073af9935e9d

https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity

Please revert all overriden changes (BuildRoot & %clean removal).

Work-around, if any:
Basically, it means we should remove the list of %if 0%{?suse_version} clauses in the rear.spec file. However, we already moved this code to init/default/005_verify_os_conf.sh and build/default/990_update_os_conf.sh so we can remove these lines if there are no objections from the team

jsmeix commented at 2018-07-11 09:13:¶

The rear.spec in
https://src.fedoraproject.org/rpms/rear/c/1b0370180d627d4c63b51fac0f31073af9935e9d
is not the one of our ReaR upstream respository
https://github.com/rear/rear/blob/master/packaging/rpm/rear.spec
so that I think this issue is not a ReaR upstream issue.

I do not mind what rear.spec is used at Fedora or at Red Hat
or at other Linux distributions particular repositories
so whatever each particular Linux distribution requests for
their particular rear.spec in their particular repository is o.k. for me.

For example I use my own rear.spec for the official rear RPM in openSUSE at
https://build.opensuse.org/package/show/Archiving/rear

As far as I see our rear.spec from our ReaR upstream respository
https://github.com/rear/rear/blob/master/packaging/rpm/rear.spec
is used for our ReaR upstream RPMs at
https://build.opensuse.org/project/show/Archiving:Backup:Rear
so that our ReaR upstream rear.spec should be first and foremost
in compliance with the requirements of the openSUSE build service
(and not with Fedora's or Red Hat's or any other Linux distribution's requirements
if the different requirements conflict with each other).

jsmeix commented at 2018-07-16 11:48:¶

@gdha
provided you agree that this issue is not a ReaR upstream issue,
can we close it or do you need it to be open for some time?

gdha commented at 2018-07-17 08:41:¶

@jsmeix I would not close this one as the creation of the os.conf file should not be handled by the spec file, and, we already have code in place whose does this. Therefore, IMHO I think we can remove this part from the spec file without breaking ReaR.
This must be tested of course.

jsmeix commented at 2018-07-17 09:13:¶

@gdha
but as far as I see in our ReaR upstream rpm.spec
https://github.com/rear/rear/blob/master/packaging/rpm/rear.spec
we do not create os.conf - or I fail to see how.

gdha commented at 2018-08-17 13:10:¶

yes we do:

$ grep -r 'os.conf' .
./lib/config-functions.sh:'$CONFIG_DIR/os.conf' and verify that your setup actually works.
./lib/config-functions.sh:            test "$OS_VENDOR" || Error "Failed to detect OS_VENDOR. You may manually specify it in $CONFIG_DIR/os.conf"
./lib/config-functions.sh:            test "$OS_VERSION" || Error "Failed to detect OS_VERSION. You may manually specify it in $CONFIG_DIR/os.conf"
./rescue/GNU/Linux/990_sysreqs.sh:elif test -f /etc/rear/os.conf ; then
./init/default/005_verify_os_conf.sh:# usr/share/rear/init/default/005_verify_os_conf.sh
./init/default/005_verify_os_conf.sh:# Purpose is to verify if the /etc/rear/os.conf file has been created already and if this is the first time
./init/default/005_verify_os_conf.sh:# then we will create a new os.conf file with the values found by the main script 'rear' (via the function
./init/default/005_verify_os_conf.sh:if [[ ! -f "$CONFIG_DIR/os.conf" ]] ; then
./init/default/005_verify_os_conf.sh:    echo "OS_VENDOR=$OS_VENDOR"    > "$CONFIG_DIR/os.conf"
./init/default/005_verify_os_conf.sh:    echo "OS_VERSION=$OS_VERSION" >> "$CONFIG_DIR/os.conf"
./init/default/005_verify_os_conf.sh:    Log "Created the $CONFIG_DIR/os.conf file with content:"
./init/default/005_verify_os_conf.sh:    cat "$CONFIG_DIR/os.conf" >&2
./build/default/990_update_os_conf.sh:# Add os/version info to os.conf in the rescue system
./build/default/990_update_os_conf.sh:local rescue_system_os_conf_file="$ROOTFS_DIR/etc/rear/os.conf"
./build/default/990_update_os_conf.sh:echo "# The following information was added automatically by the $WORKFLOW workflow:" >> $rescue_system_os_conf_file
./build/default/990_update_os_conf.sh:done >> $rescue_system_os_conf_file
./build/default/990_update_os_conf.sh:echo "# End of what was added automatically by the $WORKFLOW workflow." >> $rescue_system_os_conf_file

gdha commented at 2018-08-29 15:01:¶

https://github.com/rear/rear/commit/42316c5b469fd38fc8822ce1a0e9dfb302875e0d#diff-75bbd983a6e79d9aae84e41aaf407cb5 was a PR which removed the os.conf creation from the rear.spec file.

ReaR 2.4 and higher are already fixed. Fedora was referring to ReaR 2.3 so we are good.

gdha commented at 2018-08-30 07:24:¶

Seems we overlooked 2 lines added by Fedora people where they are still complaining about:

+ BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
and
+ %clean
+ %{__rm} -rf %{buildroot}
+ 
  %files

See details at https://src.fedoraproject.org/rpms/rear/c/1b0370180d627d4c63b51fac0f31073af9935e9d
Or you have an historical overview of the changes made by the Fedora team:
https://src.fedoraproject.org/rpms/rear/commits/master

jsmeix commented at 2018-09-26 09:37:¶

I close it because it is "fixed/solved/done".

jsmeix commented at 2019-05-06 11:44:¶

In https://github.com/rear/rear/pull/1908 that is
https://github.com/rear/rear/commit/2819c071681a19fc3382aa84bfaf1654508a64aa
both the disabled BuildRoot and the disabled defattr
need to be reenabled to make it build again on SLES11 RHEL 5 CentOS 5
see https://github.com/rear/rear/issues/2135#issuecomment-489590653

jsmeix commented at 2019-05-06 11:48:¶

I do not mind what rear.spec is used at Fedora or at Red Hat
or at other Linux distributions particular repositories
so whatever each particular Linux distribution requests for
their particular rear.spec in their particular repository is o.k. for me.

BUT

As far as I see our rear.spec from our ReaR upstream respository
https://github.com/rear/rear/blob/master/packaging/rpm/rear.spec
is used for our ReaR upstream RPMs at
https://build.opensuse.org/project/show/Archiving:Backup:Rear
so that our ReaR upstream rear.spec should be first and foremost
in compliance with the requirements of the openSUSE build service
(and not with Fedora's or Red Hat's or any other Linux distribution's requirements
if the different requirements conflict with each other).

jsmeix commented at 2019-05-06 11:51:¶

See
https://github.com/rear/rear/issues/2026#issuecomment-458493458

Removing the BuildRoot tag would violate
the "openSUSE:Specfile guidelines"

[Export of Github issue for rear/rear.]

#1855 Issue closed: Fedora rear.spec is violating Spec Maintenance and Canonicity¶