-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alternate method: Debian chroot #5
Comments
Nice, thanks! What about handling issue #3 - presumably support for local mp3s is as easy as an extra apt sources entry and I have written a wiki page comparing the approaches - please review, edit as necessary, and let me know your thoughts on the conclusion. Thanks again! |
@altruizine Did you get a chance to review the wiki page yet? Thanks ... |
I have read the Wiki document, but have very little to add. You discuss all the major issues, except perhaps that symlinking shared libraries with a different version number defeats the main purpose of library versioning: signaling incompatible API changes. Also, you do not discuss the option to copy a set of compatible libs from the chroot for use in the host system. Regarding security updates, it's worth mentioning that similar updates are available for a Debian chroot as well when set up correctly. |
Thanks! I have amended the wiki. So IIUC you are also suggesting a third possible approach, which is to use the Debian chroot purely to obtain the correct libraries, but then copy them to the host and run Spotify on the host using those copies? But wouldn't those libraries depend on other Debian shared libraries? In which case what is the advantage of copying them outside the chroot? Saving disk space by deleting the chroot after copying? |
Yes, that's the idea. You're right, the missing libraries may depend on other Debian libraries, and copying all of them likely would be the most robust solution. Yes, the main idea is to save space by not having to keep the chroot around, as well as to do away with the complexity of mounting the home and system directories into the chroot directory and setting up the chroot's sound subsystem. Also, interaction with the base system would be simpler, such as running the browser from within the Spotify client (although that can be accomplished with the help of of an unchroot wrapper). Note that I have not actually tried this method; I'm happily using a Debian Squeeze chroot on my OpenSUSE 12.1 box. |
Thanks, I updated the wiki (feel free to amend yourself too). |
The method of dynamically linking against potentially incompatible platform libraries seems to be causing various instabilities, including random crashes. An alternate method to get the spotify binary to run is to run it in a chroot environment that has the right libraries installed.
According to the Spotify website and support forum, Spotify is built using Debian Squeeze and “supported” for Ubuntu 10.04 and up. Setting up a Debian-based chroot is rather trivial thanks to the debootstrap tool, for which there is an OpenSuse port. Running the chrooted spotify from a desktop session is easy as well with the schroot tool, which also has various ports available at software.opensuse.org.
For inspiration, please have a look at this script snippet, which I'm using to install Spotify in a Debian 32-bit chroot on a 64-bit OpenSuse 12.1: https://gist.github.com/4086143
Once installed, running spotify is as easy as running
schroot -p spotify
.An alternative to running Spotify in the chroot could be to just install the chroot to snatch a compatible set of shared libraries from the Debian system, and then put those into the native install.
The text was updated successfully, but these errors were encountered: