Re: [Spacewalk-devel] upstreaming some of our .spec file changes
On Tue, Aug 06, 2013 at 05:28:09PM -0600, Lamont Peterson wrote: [snip] Well, discussions about renaming all tools and packages to spacewalk- something pop up from time to time for many years ;). Althought we mostly agree with renaming comandline tools (assuming that old names will remain at least as symlinks for compatibility reasons) we've decided not to rename rpm packages because it will make upgrades much complicated. How so? You simply Obsoletes: the old package name with the new one. You can even drop the Obsoletes: from the SPEC file after a time. Except you won't see that package as a suggested errata in RHN or Spacewalk because, well, it's a different package. So it will work by replacing the original package correctly but you will have harder time making the new package be included in the transaction. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] upstreaming some of our .spec file changes
% Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in
% the spec files (like they are in our tree. /srv/www vs /var/www anyone)
%
% Why didn't you send those %ifdefs for review? If this is the only
% thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm
% sure the Spacewalk team will be happy to consider those patches for
% master.
%
% This is something we probably should do. I think the 80% of the patch
% are SUSE/RH differences, and the minor part SUSE Manager/Spacewalk
% specific. We should upstream at least the first part.
%
% We would need to split the changes in those two. I can give you an
% overview of the changes and we can discuss now if you would be willing
% to have those upstream. I copy pasted some snippets, of course similar
% changes are across all specs.
%
% I am posting these examples so that we can discuss how to handle them
% overall.
%
% 1) apache/FHS/paths/etc changes, redhat - SUSE specifics:
%
% 1.1) Packaging differences
%
% 1.1.1) newer versions of fedora do not use defattr
%
% +%defattr(-,root,root)
%
% How do you handle those in RHEL?
The %defattr is not necessary since rpm 4.4 which is included even in RHEL 5.
So we don't need to care about it.
% 1.1.2) Release in versions. SUSE releases are generated from the build,
% so we don't use releases in dependencies, except for example a
% subpackage requiring a parent package:
%
% -Provides: %{name}-sql-virtual = %{version}-%{release}
% +Provides: %{name}-sql-virtual = %{version}
So if you have
Provides: %{name}-sql-virtual = %{version}
you'll get
spacewalk-backend-sql-virtual = 2.0.3-3.1
?
And what will gou get for Provides: %{name}-sql-virtual = %{version}-%{release}?
% 1.1.3) epochs
%
% -BuildRequires: antlr = 0:2.7.6
% +BuildRequires: antlr = 2.7.6
% (ton like these)
Does it causes errors during build time or is just using epoch uncommon in SUSE
packages?
% 1.1.4) macros
%
% This one is funny because %_localstatedir resolves to /var on Fedora :-)
%
% +%if 0%{?suse_version}
% +install -d -m 755
% $RPM_BUILD_ROOT/%{_localstatedir}/lib/spacewalk/systemlogs
% +%else
% +install -d -m 755 $RPM_BUILD_ROOT/%{_var}/spacewalk/systemlogs
% +%endif
So wouldn't be easier to change it to %{_localstatedir}/lib/spacewalk/systemlogs
in upstream?
% 1.2) Redhat does not require owning directories.
%
% A SUSE package either has to own a directory with %dir explicitly, or
% BuildRequire the owner.
%
% +%if 0%{?suse_version}
% +%dir %{rhnroot}/server
% +%endif
%
% 1.3) python/apache specifics
%
% +%if 0%{?suse_version}
% +%global apacheconfd %{_sysconfdir}/apache2/conf.d
% +%global apache_user wwwrun
% +%global apache_group www
% +%else
% %global apacheconfd %{_sysconfdir}/httpd/conf.d
% -%if 0%{?rhel} 0%{?rhel} 6
% -%{!?python_sitelib: %global python_sitelib %(%{__python} -c from
% distutils.sysconfig import get_python_lib; print get_python_lib())}
% +%global apache_user apache
% +%global apache_group apache
% +%endif
% +%if 0%{?rhel} || 0%{?suse_version}
% +%{!?py_ver: %define py_ver %(python -c import sys;
% v=sys.version_info[:2]; print '%%d.%%d'%%v 2/dev/null || echo
% PYTHON-NOT-FOUND)}
% +%{!?py_prefix: %define py_prefix %(python -c import sys; print
% sys.prefix 2/dev/null || echo PYTHON-NOT-FOUND)}
% +%{!?py_libdir: %define py_libdir %{py_prefix}/%{_lib}/python%{py_ver}}
% +%{!?python_sitelib: %define python_sitelib %(%{__python} -c from
% distutils.sysconfig import get_python_lib; print get_python_lib())}
%
% +%if 0%{?suse_version}
% +BuildRequires: spacewalk-config
% +Requires(pre): apache2
% +PreReq: %fillup_prereq
% +%else
% +Requires(pre): httpd
% +%endif
%
% +%if 0%{?suse_version}
% +BuildRequires: python-devel
% +%if 0%{?suse_version} = 1110
% +Requires: python-base
% +%else
% +Requires: python
% +Requires: python-hashlib
% +%endif
% +%else
% BuildRequires: python2-devel
% Conflicts: %{name} 1.7.0
% Requires: python-hashlib
% BuildRequires: python-hashlib
% +%endif
%
% 1.4) apache user/groups
%
% if [ -f $OLD_SECRET_FILE ]; then
% -install -d -m 750 -o root -g apache %{rhnconf}
% +install -d -m 750 -o root -g %{apache_group} %{rhnconf}
% mv ${OLD_SECRET_FILE}* %{rhnconf}
% fi
%
% -%attr(755,root,apache) %dir %{rhnconfigdefaults}
% -%attr(644,root,apache) %{rhnconfigdefaults}/rhn.conf
% +%attr(755,root,%{apache_group}) %dir %{rhnconfigdefaults}
% +%attr(644,root,%{apache_group}) %{rhnconfigdefaults}/rhn.conf
No problem adding different user/group defs into spec (until it's still working
in Fedora/RHEL).
% Some Fedora specifics are in the Makefiles, so we fix them in the spec:
%
% +%if !0%{?suse_version}
% +sed -i 's/^INSTALL_DEST.*/INSTALL_DEST = \/etc\/httpd\/conf.d/'
% apache-conf/Makefile
% +%endif
This should be definitely done in more elegant way than modifying
makefile in build time.
% 1.4.1) apache paths
%
% +%define wwwdocroot %{_var}/www/html
%
% -install -d -m 755 %{buildroot}%{_var}/www/html
%
Re: [Spacewalk-devel] upstreaming some of our .spec file changes
[snip] Well, discussions about renaming all tools and packages to spacewalk- something pop up from time to time for many years ;). Althought we mostly agree with renaming comandline tools (assuming that old names will remain at least as symlinks for compatibility reasons) we've decided not to rename rpm packages because it will make upgrades much complicated. How so? You simply Obsoletes: the old package name with the new one. You can even drop the Obsoletes: from the SPEC file after a time. [snip] -- Lamont Peterson lamont.peter...@imail.org Senior Systems Administrator Intermountain Healthcare ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] upstreaming some of our .spec file changes
On 01/08/13 10:05, Jan Pazdziora wrote:
Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in
the spec files (like they are in our tree. /srv/www vs /var/www anyone)
Why didn't you send those %ifdefs for review? If this is the only
thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm
sure the Spacewalk team will be happy to consider those patches for
master.
This is something we probably should do. I think the 80% of the patch
are SUSE/RH differences, and the minor part SUSE Manager/Spacewalk
specific. We should upstream at least the first part.
We would need to split the changes in those two. I can give you an
overview of the changes and we can discuss now if you would be willing
to have those upstream. I copy pasted some snippets, of course similar
changes are across all specs.
I am posting these examples so that we can discuss how to handle them
overall.
1) apache/FHS/paths/etc changes, redhat - SUSE specifics:
1.1) Packaging differences
1.1.1) newer versions of fedora do not use defattr
+%defattr(-,root,root)
How do you handle those in RHEL?
1.1.2) Release in versions. SUSE releases are generated from the build,
so we don't use releases in dependencies, except for example a
subpackage requiring a parent package:
-Provides: %{name}-sql-virtual = %{version}-%{release}
+Provides: %{name}-sql-virtual = %{version}
1.1.3) epochs
-BuildRequires: antlr = 0:2.7.6
+BuildRequires: antlr = 2.7.6
(ton like these)
1.1.4) macros
This one is funny because %_localstatedir resolves to /var on Fedora :-)
+%if 0%{?suse_version}
+install -d -m 755
$RPM_BUILD_ROOT/%{_localstatedir}/lib/spacewalk/systemlogs
+%else
+install -d -m 755 $RPM_BUILD_ROOT/%{_var}/spacewalk/systemlogs
+%endif
1.2) Redhat does not require owning directories.
A SUSE package either has to own a directory with %dir explicitly, or
BuildRequire the owner.
+%if 0%{?suse_version}
+%dir %{rhnroot}/server
+%endif
1.3) python/apache specifics
+%if 0%{?suse_version}
+%global apacheconfd %{_sysconfdir}/apache2/conf.d
+%global apache_user wwwrun
+%global apache_group www
+%else
%global apacheconfd %{_sysconfdir}/httpd/conf.d
-%if 0%{?rhel} 0%{?rhel} 6
-%{!?python_sitelib: %global python_sitelib %(%{__python} -c from
distutils.sysconfig import get_python_lib; print get_python_lib())}
+%global apache_user apache
+%global apache_group apache
+%endif
+%if 0%{?rhel} || 0%{?suse_version}
+%{!?py_ver: %define py_ver %(python -c import sys;
v=sys.version_info[:2]; print '%%d.%%d'%%v 2/dev/null || echo
PYTHON-NOT-FOUND)}
+%{!?py_prefix: %define py_prefix %(python -c import sys; print
sys.prefix 2/dev/null || echo PYTHON-NOT-FOUND)}
+%{!?py_libdir: %define py_libdir %{py_prefix}/%{_lib}/python%{py_ver}}
+%{!?python_sitelib: %define python_sitelib %(%{__python} -c from
distutils.sysconfig import get_python_lib; print get_python_lib())}
+%if 0%{?suse_version}
+BuildRequires: spacewalk-config
+Requires(pre): apache2
+PreReq: %fillup_prereq
+%else
+Requires(pre): httpd
+%endif
+%if 0%{?suse_version}
+BuildRequires: python-devel
+%if 0%{?suse_version} = 1110
+Requires: python-base
+%else
+Requires: python
+Requires: python-hashlib
+%endif
+%else
BuildRequires: python2-devel
Conflicts: %{name} 1.7.0
Requires: python-hashlib
BuildRequires: python-hashlib
+%endif
1.4) apache user/groups
if [ -f $OLD_SECRET_FILE ]; then
-install -d -m 750 -o root -g apache %{rhnconf}
+install -d -m 750 -o root -g %{apache_group} %{rhnconf}
mv ${OLD_SECRET_FILE}* %{rhnconf}
fi
-%attr(755,root,apache) %dir %{rhnconfigdefaults}
-%attr(644,root,apache) %{rhnconfigdefaults}/rhn.conf
+%attr(755,root,%{apache_group}) %dir %{rhnconfigdefaults}
+%attr(644,root,%{apache_group}) %{rhnconfigdefaults}/rhn.conf
Some Fedora specifics are in the Makefiles, so we fix them in the spec:
+%if !0%{?suse_version}
+sed -i 's/^INSTALL_DEST.*/INSTALL_DEST = \/etc\/httpd\/conf.d/'
apache-conf/Makefile
+%endif
1.4.1) apache paths
+%define wwwdocroot %{_var}/www/html
-install -d -m 755 %{buildroot}%{_var}/www/html
+install -d -m 755 %{buildroot}/%{wwwdocroot}
1.5) SUSE specifics
+%post tools
+%{fillup_only -nd reposync rhn}
%files
+/var/adm/fillup-templates/sysconfig.reposync
+%if 0%{?suse_version} 0%{?suse_version} 1210
+Requires(preun): %fillup_prereq %insserv_prereq
+%endif
+%if 0%{?suse_version}
+%py_compile %{buildroot}/%{rhnroot}
+%py_compile -O %{buildroot}/%{rhnroot}
+%endif
2) Debranding: those should be straightforward, except for renamed packages
-Summary: Core functions providing SQL connectivity for the RHN backend
modules
+Summary: Core functions providing SQL connectivity for the Spacewalk
backend modules
Renamed specs:
rhnsd - spacewalksd
rhn-client-tools spacewalk-client-tools
Some stuff due to renamed packages:
-Requires: rhn-check
+Requires: %{rhn_check}
If we can discuss those, I can prepare a patch with most of the changes
that are mostly distro specific and not product
