Cleaned up the xpra.spec. The build dependencies depend on packages in #605.
Removed the generic option. If there is a need we can break the package out into components such as (client, server, codecs, opengl, etc...)
Removed bunch of old crufty options.
I like (and will try to merge):
BuildRequires
_datadir and other macros we should already be using
#define, etc)
but there are too many changes in this specfile for me to apply wholesale:
CentOS, Fedora can be built with dynamically linked modules (via rpmfusion) - and this is what we will continue to provide as there is absolutely no way we can take the responsibility for updating all those packages whenever there are security issues that require a rebuild with newer libs (we just don't have the manpower)
chcon workarounds disappeared?
%debug_package?
Responding to your questions/points
texrel_shlib_t is not preferred (1) (2). I don't understand text relocation, so I have no objection if this is kept. A comment explaining why this workaround is in place would be useful, though.
%debug_package, I removed it since debug packages get built automatically with mock. I have no strong feelings here, though if you decided to keep it, I think the line should go towards the top of the SPEC file. Note, most packages do not define %debug_package.
(1) http://danwalsh.livejournal.com/2006/05/11/ (see execmod) (2) http://danwalsh.livejournal.com/13716.html
textrel_shlib_t - I think we can drop it from the new spec file, for the old ones I've reopened #284
%debug_package, I'll do some testing - I don't think I'll be switching to mock just yet (to support all the builds during the transition period) and so I may still need it
Some changes already applied: r7101 + r7103
Anything more than those and I quickly ran into problems building on at least one platform. Please re-submit incremental changes (similar to the two commits above) instead of wholesale changes.
Some questions / remarks:
python2_sitelib - why do we need this? doesn't seem to be used anywhere.
BuildRequires should be updated to use the xpra private library headers from #613 (ie: xpra-libvpx-devel) - but only for those distributions that do not provide the headers we need out of the box (libvpx-devel is in Fedora and centos7, too old in centos6 - so there will need to be some ugly logic in there)
%post and %postun steps remove the check for fedora, have you tested this on oldies like centos5?
/usr/bin/update-desktop-database and /bin/touch ?
old_xdg remains but include_egg got changed to a test for el5, I don't mind which is used but it has to be consistent
--with-Xdummy will not work on many centos versions
$RPM_BUILD_ROOT vs %buildroot - I believe the latter does not work on centos5...
PS: found a good reference on which macros are available in which versions here: zarb.org : macros
python2_sitelib: we don't need it. As we we are using python2_sitearch. I like defining both, it doesn't do any harm, personal preference really.
BuildRequires: I did the work for this, I thought I attached it to this ticket, but apparently I did not. I will merge my work into the current spec (svn) and create a new ticket.
%post and %postun: Do you plan to still support el5? I want to say I tested this spec on EL5/EL6/Fedora 19/Fedora 20. However, it has been a while ago and I don't remember. Retesting would probably be useful.
%buildroot works with EL5 within a mock environment. I believe mock is using the rpmbuild version that ships with EL5.
regarding
%postand%postun: Do you plan to still support el5?
Yes, 0.14.x will be the last branch to support EL5, and it will be a LTS release.
As soon as development opens for 0.15.x, I will drop support for EL5, python24 and python25, old versions of pygtk, etc. At last!
(I wished I could drop python26 too..)
regards to Xdummy it is supported on EL6/EL7. Do you want to continue to support EL5?
As per above, yes.
Note: although Xdummy works on EL6.3 and later, it doesn't on 6.2 and earlier. (IIRC, I could be off by one on the version numbers)
And I have to provide rpms for 6.2.
I want to say I tested this spec on EL5/EL6/Fedora 19/Fedora 20...
OK, I was only asking because normally special cases don't end up in the code (specfile in this case) unless I've hit some problems.
Applied in r7108.
regarding the absolute path: this is what fedora recommends...
OK, also merged in r7107.
Does this also apply to commands like rm and cd? How do we make the distinction?
Note to self: if all goes well, we can probably drop the static modules and also get rid of all the selinux stuff.
Lots of cleanups in r7283.
Does this also apply to commands like
rmandcd? How do we make the distinction?
I've seen both the full path specified and just the command specified. I think, in general, the best practice would be to use use the absolute path. You won't have to worry about functions, aliases, or paths that way.
One Major Issue: BuildRequires: setuptool should be BuildRequires: python-setuptools
Xpra should be installed in python_sitearch in the case of x86_64 that would be /usr/lib64
$ find /usr/lib64/python2.6/site-packages/ | grep '\.so' | wc -l 85 $ find /usr/lib/python2.6/site-packages/ | grep '\.so' | wc -l 0
See this mark on the difference between sitelib and sitearch:
You got it right. If you don't have any platform-specific code, use %{python_sitelib} exclusively. If you do, like C-binding stuff, then all
these should go to %{python_sitearch}, since the location will be different on 64-bit architectures.
http://www.redhat.com/archives/fedora-extras-list/2006-January/msg00513.html
xpra.spec patch based on r7292
setuptool vs python-setuptools fix in r7293
sitearch vs sitelib in r7294
avahi-ui-tools dep removed in r7295 (see commit message for details on this insanity)
I hope the latter does not cause problems somewhere.. (centos5?)
0.14.0 has been shipped with all these changes, closing at last!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/606