Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fedora rear.spec is violating Spec Maintenance and Canonicity #1855

Closed
gdha opened this issue Jul 11, 2018 · 11 comments
Closed

Fedora rear.spec is violating Spec Maintenance and Canonicity #1855

gdha opened this issue Jul 11, 2018 · 11 comments

Comments

@gdha
Copy link
Member

gdha commented Jul 11, 2018

  • 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
@gdha gdha added the cleanup label Jul 11, 2018
@gdha gdha added this to the ReaR v2.5 milestone Jul 11, 2018
@gdha gdha assigned gdha and jsmeix Jul 11, 2018
@jsmeix jsmeix added the not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. label Jul 11, 2018
@jsmeix
Copy link
Member

jsmeix commented Jul 11, 2018

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 jsmeix changed the title rear is violating Spec Maintenance and Canonicity Fedora rear.spec is violating Spec Maintenance and Canonicity Jul 11, 2018
@jsmeix
Copy link
Member

jsmeix commented Jul 16, 2018

@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
Copy link
Member Author

gdha commented Jul 17, 2018

@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
Copy link
Member

jsmeix commented Jul 17, 2018

@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
Copy link
Member Author

gdha commented Aug 17, 2018

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
Copy link
Member Author

gdha commented Aug 29, 2018

42316c5#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 gdha closed this as completed Aug 29, 2018
@gdha gdha reopened this Aug 30, 2018
@gdha
Copy link
Member Author

gdha commented Aug 30, 2018

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

@gdha gdha added fixed / solved / done and removed not ReaR / invalid The root cause is not in the ReaR code or ReaR is misused. labels Aug 31, 2018
@jsmeix
Copy link
Member

jsmeix commented Sep 26, 2018

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

@jsmeix
Copy link
Member

jsmeix commented May 6, 2019

In #1908 that is
2819c07
both the disabled BuildRoot and the disabled defattr
need to be reenabled to make it build again on SLES11 RHEL 5 CentOS 5
see #2135 (comment)

@jsmeix
Copy link
Member

jsmeix commented May 6, 2019

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
Copy link
Member

jsmeix commented May 6, 2019

See
#2026 (comment)

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants