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

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565 --- Comment #8 from Jonathan Dieter <jdieter(a)gmail.com&gt; 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.fc... 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.