Fetch SUSE and Spotify versions on the fly.

[dradtke]

This PR removes the hard-coded SUSE and Spotify versions, and instead parses /etc/os-release and http://repository.spotify.com/pool/non-free/s/spotify respectively at the time the installation is run. With these changes I was able to get Spotify installed on openSUSE 13.2, and I suspect that it will work for future versions as well.

[aspiers]

Thanks! This approach sounds much more future-proof. I have some nitpicks though ...

[aspiers]

I think it would be better to squash all 3 commits into a single one (see this guide if you need help with that).

[dradtke]

I made some updates based on your suggestions and squashed them all into a single commit. Let me know what you think. =)

[aspiers]

I still don't follow why you removed this, as it goes directly against #35.

[aspiers]

Awesome, thanks! We're very close now - just indentation and the ffmpeg question blocking merge.

[dradtke]

Whoops, not sure what happened there.

[dradtke]

I didn't delete the ffmpeg recommendation, I think I just created my fork before that change was added, and I forgot to merge new changes from your branch in. In any case, I added ffmpeg back in, cleaned up the tabs, and squashed everything into one commit, so hopefully it looks good to go.

[aspiers]

Thanks! Taking a look ...

[aspiers]

Oh crap, I just realised that whilst your dynamic approach to determining the version is great for the ./install-spotify.sh installation method, it totally fails for building the spotify-installer package. In other words, your pull request neglects to take care of the version in spotify-installer.spec, so if I merged it, it would break that approach (not that it currently works anyway ...).

I can think of the following possible solutions:

1. Ditch support for the spotify-installer package, and only support running install-spotify.sh directly. That would result in orphaning the downstream Packman package.
2. Remove spotify-installer.spec and declare that as "owned" by the Packman package, and then merge this. Maybe a source service could even be constructed which dynamically determines the version number, although then the version discovery is duplicated in two places. Ugh. That aside, this approach seems more in keeping with the standard separation of concerns between upstream source and downstream packaging.
3. Resurrect Adapt to spotify-make, #4  #19 and fix integration with spotify-make.
4. Ditch the whole package and focus on supporting spotify-make instead (e.g. adapt the Packman package to wrap around it).
5. Just acknowledge that Spotify is pure evil and boycott it ;-)

Option 5 is obviously the right thing to do. However, since we are weak and foolish humans, maybe option 2 is the most realistic solution for the short-term, and option 4 for the long term. Thoughts?

[aspiers]

Note: merging this PR would fix #29 and #36. But we still need to resolve #33.

[aspiers]

Hmm, just occurred to me that merging this PR would mean that one version of the spotify-installer package (e.g. as built on PackMan) would most likely work for installing multiple versions of Spotify as they come out. IOW, it makes the version of the installer rpm independent of the version of Spotify it's installing. So we could switch the installer rpm to a different versioning system, to avoid the misleading connotation that it has to match the exact version of Spotify being installed. This way we wouldn't have to worry about updating its version unless the install-spotify.sh script itself changed.

[bclouser]

This pull request was spot on as I had cloned the Repo and had issues until I saw this. So thanks!

As far as resolving #33. I just used the opensuse package for libgcrypt.so.11 provided here: https://software.opensuse.org/package/libgcrypt11 ( which it seems you are already aware of)

Are there plans afoot to incorporate the zypper check of libgcrypt.so.11 and get it if it doesn't exist? mentioned on #38

[aspiers]

@dradtke Do you have any thoughts on my comments?

[aspiers]

@bclouser Thanks for the info but please let's not pollute this issue with discussion of unrelated topics - I'm already confused enough as it is ;-)

[ftonello]

Any idea when this will be integrated? The current version is too old.

[dastergon]

Yes please. It would be great to see this PR merged!