[lxc-devel] Building upstream lxc.spec on openSUSE OBS
Michael H. Warfield
mhw at WittsEnd.com
Sun Aug 17 18:30:30 UTC 2014
On Thu, 2014-08-14 at 21:52 +0200, Johannes Kastl wrote:
> On 13.08.2014 21:10 Johannes Kastl wrote:
> > On 13.08.2014 20:41 Johannes Kastl wrote:
> >> Hi MIke, hi Dwight,
> >
> >> sorry for the long long delay. I finally got time to work on
> >> that a little, and produced a patch against lxc.spec.in. At
> >> least, I got a working spec, and I am in the middle of patching.
> >> Stay tuned...
> >
> > Here it is. I hope this patch has the right format, if not just
> > say what's wrong.
> I attach the second version of my patch, which has been cleaned up,
> has clearer distinctions between distributions and builds on CentOS7
> (if I comment out the BuildRequires for docbook2x).
I would have liked a cleaner patch with fewer cosmetic changes or style
changes. It's making the merge distinctly more difficult.
-%{_libdir}/python3.3/site-packages/_lxc*
-%{_libdir}/python3.3/site-packages/lxc/*
+%{_libdir}/python3.3/site-packages/_%{name}*
+%{_libdir}/python3.3/site-packages/%{name}/*
While these changes may be nice, I would have rather had things like
this broken out in a separate clean-up patch rather than gemixed with
functional changes.
You have two external sources called out here:
+%if 0%{?suse_version} >= 1210
+Source1: README.SUSE
+Source2: lxc-createconfig.in
+%endif
I don't think that's going to fly. That would mean that someone taking
our source tree would not be able to build the rpm on Suse unless they
obtained those sources from somewhere else. That really needs to be
submitted and integrated into the source tree to be acceptable.
Why this change in the License? I'm not saying either is right or wrong
or that they're not functionally equivalent, but there must have been
some reason for changing it and I would like to know what it was...
Summary: Linux Containers userspace tools
Group: Applications/System
-License: LGPLv2+
+License: LGPL-2.0+
BuildRoot: %{_tmppath}/%{name}-%{version}-build
You changed the man directory code like this:
from this:
-%{_mandir}/man1/lxc*
-%{_mandir}/man5/lxc*
-%{_mandir}/man7/lxc*
-%{_mandir}/ja/man1/lxc*
-%{_mandir}/ja/man5/lxc*
-%{_mandir}/ja/man7/lxc*
to this:
+# openSUSE/SUSE
+%if %{defined suse_version}
+%{_mandir}/man[^3]/*
+# not openSUSE/SUSE
+%else
+%if %{undefined rhel}
+%{_mandir}/man[^3]/*
+%{_mandir}/ja/*
+%endif
Looks like the man dir is the same for Suse and not Suse other than the
Japanese pages (which I believe is what we need docbook2X for) or when
rhel is defined. I recall seeing a remark from you over the use of that
regex on rhel, as well. So you're NOT installing any man pages on
RHEL/CentOS? Why make this change (other than excluding the ja pages
under Suse)? Do you have some specific need for that regex at all?
What is the problem with the way it was coded? Were we missing
something in another section?
Seems like there were a number of changes in here that were not
necessary to make it build under Suse (or it's unclear why they were
necessary). Can we split the functionally substantive changes from the
purely cosmetic changes and style changes?
> Can someone build it on CentOS 5/6/7 where docbook2x is available?
Right now, let's focus on getting the patch into an acceptable form with
minimal cosmetic changes and undo the use of that regex for the man
pages.
> Regards,
> Johannes
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
--
Michael H. Warfield (AI4NB) | (770) 978-7061 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140817/3191f614/attachment.sig>
More information about the lxc-devel
mailing list