[Bug 2565] Review-Request: spotify-client - streaming music player

[RPM Fusion Bugzilla]

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565

--- Comment #8 from Jonathan Dieter <jdieter at gmail.com> 2012-11-12 12:57:15 CET ---
Ok, I've looked at this and found a number of things that I think need to be
changed and have tested to make sure the changes make sense:

1. I'm not a huge fan of %ghosted files and installing symlinks in %post.  I
think it makes more sense to install the symlinks in %install, have them
dangle, and just make sure we require the right files (which we have to do
anyway).

2. Rather than owning each individual file in %{_libdir}/spotify-client, I
think it makes the more sense to just own the directory.

3. The problems listed in comments #6 and #7 were mainly because libcef.so
wasn't marked as executable, so rpmbuild wasn't properly generating the
automatic build requires.  By making libcef.so executable and creating custom
requires and provides scripts, we get all the requires listed properly, and, as
a bonus, no longer have to manually require the symlinked libraries.

4. Rpaths are bad.  See
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath.  To top it
off, chrpath only works on the arch that the binary was built for, so you can
use x86_64 chrpath to change a i686 binary's rpath.  This may or may not cause
problems with RPM Fusion's builders.  At the very least, it prevents a user
from building a i686 package on an x86_64 system.  Using LD_LIBRARY_PATH in
spotify.sh achieves the same result without needing chrpath.

5. I think it makes sense to have spotify.sh as a separate %SOURCE rather than
embedded in the spec, mainly for neatness' sake.

An updated SPEC which incorporates all of the above is here:
Spec: http://lesloueizeh.com/jdieter/spotify-client.spec
SRPM:
http://lesloueizeh.com/jdieter/spotify-client-0.8.4.103.g9cb177b.260-2.fc17.src.rpm

rpmlint output:
$ rpmlint spotify-client.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
$ rpmlint spotify-client-0.8.4.103.g9cb177b.260-2.fc18.src.rpm 
spotify-client.src: W: strange-permission spotify_find_provides.sh 0755L
spotify-client.src: W: strange-permission spotify_find_requires.sh 0755L
1 packages and 0 specfiles checked; 0 errors, 2 warnings.
$ rpmlint spotify-client-0.8.4.103.g9cb177b.260-2.fc18.x86_64.rpm 
spotify-client.x86_64: E: binary-or-shlib-defines-rpath
/usr/lib64/spotify-client/spotify ['/usr/share/spotify']
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libsmime3.so.1d ../libsmime3.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libplc4.so.0d ../libplc4.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libnspr4.so.0d ../libnspr4.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libnssutil3.so.1d ../libnssutil3.so
spotify-client.x86_64: W: dangling-relative-symlink
/usr/lib64/spotify-client/libnss3.so.1d ../libnss3.so
spotify-client.x86_64: W: no-manual-page-for-binary spotify
1 packages and 0 specfiles checked; 1 errors, 6 warnings.

The strange-permission warnings can be ignored as the spotify_find_* scripts
need to have permissions of 755.  I don't know if we should deal with the
binary-or-shlib-defines-rpath error as that would involve running chrpath on
%{_libdir}/spotify-client/spotify to remove the rpath.  The
dangling-relative-symlink warnings can be ignored as the necessary files are
required by the package.  And, finally, no-manual-page-for-binary can be
ignored as no man page exists.

-- 
Configure bugmail: https://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.