#606 closed enhancement (fixed)
cleaned up xpra.spec
Reported by: | pyther | Owned by: | pyther |
---|---|---|---|
Priority: | major | Milestone: | 0.14 |
Component: | android | Version: | 0.12.x |
Keywords: | Cc: |
Description
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.
Attachments (2)
Change History (14)
Changed 8 years ago by
comment:1 Changed 8 years ago by
Owner: | changed from Antoine Martin to pyther |
---|
comment:2 Changed 8 years ago by
Responding to your questions/points
- we talked about this in irc
- In regards to #603, I agree the workaround should be removed.
- I removed the chcon workarounds because xpra works on EL6 and Fedora 20 with selinux without the workaround. I am not an expert, but it would appear that setting type
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.
- Regarding
%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
comment:3 Changed 8 years ago by
Owner: | changed from pyther to Antoine Martin |
---|---|
Status: | new → assigned |
- as per #613: it looks like we'll be shipping minimal media libraries for quite a few distros
- thanks for the links on
textrel_shlib_t
- I think we can drop it from the new spec file, for the old ones I've reopened #284 - as for
%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
comment:4 Changed 8 years ago by
Owner: | changed from Antoine Martin to pyther |
---|---|
Status: | assigned → new |
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)- the
%post
and%postun
steps remove the check for fedora, have you tested this on oldies like centos5? - why add an absolute path to
/usr/bin/update-desktop-database
and/bin/touch
? old_xdg
remains butinclude_egg
got changed to a test forel5
, 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
comment:5 Changed 8 years ago by
python2_sitelib
: we don't need it. As we we are usingpython2_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.
- regarding
%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.
- regards to Xdummy it is supported on EL6/EL7. Do you want to continue to support EL5?
%buildroot
works with EL5 within a mock environment. I believe mock is using the rpmbuild version that ships with EL5.
- regarding the absolute path: this is what fedora recommends: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache
comment:6 Changed 8 years ago by
regarding
%post
and%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.
comment:8 Changed 8 years ago by
Does this also apply to commands like
rm
andcd
? 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.
comment:9 Changed 8 years ago by
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
comment:10 Changed 8 years ago by
comment:11 Changed 8 years ago by
Milestone: | 0.15 → 0.14 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
0.14.0 has been shipped with all these changes, closing at last!
comment:12 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/606
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
?