[GH-ISSUE #727] Release precompiled binaries

kerem commented

2026-02-27 19:30:25 +03:00

Owner

Originally created by @MrksHfmn on GitHub (May 10, 2021).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/727

It would be great if besides the source code also precompiled binaries for the most common processors would be provided.

Originally created by @MrksHfmn on GitHub (May 10, 2021). Original GitHub issue: https://github.com/librespot-org/librespot/issues/727 It would be great if besides the source code also precompiled binaries for the most common processors would be provided.

kerem

2026-02-27 19:30:25 +03:00

closed this issue
added the
wontfix

compilation
labels

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@ashthespy commented on GitHub (May 10, 2021):

There are already a few distros picking this up and packing it may be you are lucky? :-)

@ashthespy commented on GitHub (May 10, 2021): There are already a few distros picking this up and [packing it](https://github.com/librespot-org/librespot#packages) may be you are lucky? :-)

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@Johannesd3 commented on GitHub (May 10, 2021):

Maybe we could do something similar to this: https://github.com/BurntSushi/ripgrep/blob/master/.github/workflows/release.yml

@Johannesd3 commented on GitHub (May 10, 2021): Maybe we could do something similar to this: https://github.com/BurntSushi/ripgrep/blob/master/.github/workflows/release.yml

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@ashthespy commented on GitHub (May 10, 2021):

My 0.2c -- we should make the switch to leaving this repo as the library, and have librespotd become the current librespot binary. There we can package and create binaries :-)

@ashthespy commented on GitHub (May 10, 2021): My 0.2c -- we should make the switch to leaving this repo as the library, and have [`librespotd`](https://github.com/librespot-org/librespotd) become the current `librespot` binary. There we can package and create binaries :-)

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@Johannesd3 commented on GitHub (May 10, 2021):

If it would be that easy. https://github.com/librespot-org/librespot/discussions/648#discussioncomment-532108

@Johannesd3 commented on GitHub (May 10, 2021): If it would be that easy. https://github.com/librespot-org/librespot/discussions/648#discussioncomment-532108

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 14, 2021):

My opinion if it's worth anything is that it's not up to you guys to build binaries/packages for several different architectures/OS's/Distros. That's a whole job in and of itself. That's what packagers are for. That's their job. It's a waste of your time that could be spent doing literally anything else more useful.

@JasonLG1979 commented on GitHub (May 14, 2021): My opinion if it's worth anything is that it's not up to you guys to build binaries/packages for several different architectures/OS's/Distros. That's a whole job in and of itself. That's what packagers are for. That's their job. It's a waste of your time that could be spent doing literally anything else more useful.

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@kingosticks commented on GitHub (May 15, 2021):

I disagree. While setting up/debugging github workflows is a bit of a faff, once done it's invaluable. And we already have much of the flows in place. Even if it's just binaries rather than packages, it immediately opens up the very latest code for more people to try. It's particularly valuable since librespot has so few tests, being able to have binaries automatically available for every commit with zero-effort could provide more confidence in larger changes. As long as the librespot program still exists, and there's someone out there interested in doing this, this is useful. You could argue it's far more useful than some of these complicated audio features but I try not to pass judgement on what itches people want to scratch.

@kingosticks commented on GitHub (May 15, 2021): I disagree. While setting up/debugging github workflows is a bit of a faff, once done it's invaluable. And we already have much of the flows in place. Even if it's just binaries rather than packages, it immediately opens up the very latest code for more people to try. It's particularly valuable since librespot has so few tests, being able to have binaries automatically available for every commit with zero-effort could provide more confidence in larger changes. As long as the librespot program still exists, and there's someone out there interested in doing this, this is useful. You could argue it's far more useful than some of these complicated audio features but I try not to pass judgement on what itches people want to scratch.

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 15, 2021):

Even if it's just binaries rather than packages, it immediately opens up the very latest code for more people to try. It's particularly valuable since librespot has so few tests,

Most people do not use librespot directly as-is, they use it as a lib, as is the case with spotifyd or as some sort of service or plugin. It makes a lot more sense for those projects to provide binaries/packages.

As long as the librespot program still exists, and there's someone out there interested in doing this, this is useful.

Up until recently librespot hasn't been a very active project and it currently has very few devs. Like I said packaging and packaging related bugs is a whole job itself. In a perfect world sure there would be a person or team that all they did was packaging but that's not the case. Currently IMHO it's a waste of resources.

@JasonLG1979 commented on GitHub (May 15, 2021): > Even if it's just binaries rather than packages, it immediately opens up the very latest code for more people to try. It's particularly valuable since librespot has so few tests, Most people do not use librespot directly as-is, they use it as a lib, as is the case with spotifyd or as some sort of service or plugin. It makes a lot more sense for those projects to provide binaries/packages. > As long as the librespot program still exists, and there's someone out there interested in doing this, this is useful. Up until recently librespot hasn't been a very active project and it currently has very few devs. Like I said packaging and packaging related bugs is a whole job itself. In a perfect world sure there would be a person or team that all they did was packaging but that's not the case. Currently IMHO it's a waste of resources.

kerem commented

2026-02-27 19:30:25 +03:00

Author

Owner

@michaelherger commented on GitHub (May 15, 2021):

There are people who can help with the code, and there are people who have other strengths. I considered creating a Github action for my fork of librespot to automatically build binaries for various Linux flavors. If I submitted a PR then this certainly would not be a waste of resource which could have been spent on the code. Because I can't really help with Rust 😁.

@michaelherger commented on GitHub (May 15, 2021): There are people who can help with the code, and there are people who have other strengths. I considered creating a Github action for my fork of librespot to automatically build binaries for various Linux flavors. If I submitted a PR then this certainly would not be a waste of resource which could have been spent on the code. Because I can't really help with Rust 😁.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 15, 2021):

If I submitted a PR then this certainly would not be a waste of resource which could have been spent on the code.

The actual building of binaries is not hard. I'm talking about supporting those binaries. That's the thing that takes up time. You would also need to commit to supporting the builds.

@JasonLG1979 commented on GitHub (May 15, 2021): > If I submitted a PR then this certainly would not be a waste of resource which could have been spent on the code. The actual building of binaries is not hard. I'm talking about supporting those binaries. That's the thing that takes up time. You would also need to commit to supporting the builds.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@Johannesd3 commented on GitHub (May 15, 2021):

The actual building of binaries is not hard. I'm talking about supporting those binaries. That's the thing that takes up time. You would also need to commit to supporting the builds.

Especially with Rust, it's not that difficult. Please consider that on every PR or push a complete build of the application on multiple platforms is created, and it would just be necessary to safe the artifacts.

@Johannesd3 commented on GitHub (May 15, 2021): > The actual building of binaries is not hard. I'm talking about supporting those binaries. That's the thing that takes up time. You would also need to commit to supporting the builds. Especially with Rust, it's not that difficult. Please consider that on every PR or push a complete build of the application on multiple platforms is created, and it would just be necessary to safe the artifacts.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 15, 2021):

Especially with Rust, it's not that difficult. Please consider that on every PR or push a complete build of the application on multiple platforms is created, and it would just be necessary to safe the artifacts.

My concern is that it would end up like the current situation with all of the backends. You'd end up with a bunch of drive-by PR's for architectures that are never really tested or supported properly. IMHO it's better for binaries to be released by downstream projects. If/when they run into non-architecture specific issues they can push the bugs back upstream. To me it's kinda an extension of the separation of concerns.

@JasonLG1979 commented on GitHub (May 15, 2021): > Especially with Rust, it's not that difficult. Please consider that on every PR or push a complete build of the application on multiple platforms is created, and it would just be necessary to safe the artifacts. My concern is that it would end up like the current situation with all of the backends. You'd end up with a bunch of drive-by PR's for architectures that are never really tested or supported properly. IMHO it's better for binaries to be released by downstream projects. If/when they run into non-architecture specific issues they can push the bugs back upstream. To me it's kinda an extension of the separation of concerns.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@kingosticks commented on GitHub (May 15, 2021):

I'm talking about supporting those binaries.

We already end up providing support for these packaged versions, annoying as that is. The only difference with this idea is that we control (and better understand) the environment they are run under. Or we simply provide them with zero support, which is perfectly valid.

When I looked the other week there was an upload-artifact (or something) github flow command that looked like it could be added to what we ready have but I can't remember why I didn't take it any further. I think I was specifically looking to apply it to the rpi builds because the idea of people resorting to compiling from source on the target is a waste of time; maybe i lost interest when it seemed the old rpi docker build env would need to be used (and I don't know if it even still works) rather than what we currently have for building - I can't remember, my brain is mush this week.

Edit

Most people do not use librespot directly as-is, they use it as a lib

What are you basing this assertion on? I distributed it as-as as part of a raspberry pi based image. I don't see why others wouldn't also do that. You'll be surprised how other people use things, it's just as often the opposite of what you think/intended!

@kingosticks commented on GitHub (May 15, 2021): > I'm talking about supporting those binaries. We already end up providing support for these packaged versions, annoying as that is. The only difference with this idea is that we control (and better understand) the environment they are run under. Or we simply provide them with zero support, which is perfectly valid. When I looked the other week there was an `upload-artifact` (or something) github flow command that looked like it could be added to what we ready have but I can't remember why I didn't take it any further. I think I was specifically looking to apply it to the rpi builds because the idea of people resorting to compiling from source on the target is a waste of time; maybe i lost interest when it seemed the old rpi docker build env would need to be used (and I don't know if it even still works) rather than what we currently have for building - I can't remember, my brain is mush this week. Edit > Most people do not use librespot directly as-is, they use it as a lib What are you basing this assertion on? I distributed it as-as as part of a raspberry pi based image. I don't see why others wouldn't also do that. You'll be surprised how other people use things, it's just as often the opposite of what you think/intended!

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 15, 2021):

We already end up providing support for these packaged versions, annoying as that is. The only difference with this idea is that we control (and better understand) the environment they are run under. Or we simply provide them with zero support, which is perfectly valid.

You can specifically say in bold print that you don't support the binaries you release but that will not stop people from demanding support. Even in that case prepare for a huge up-tick in noise.

@JasonLG1979 commented on GitHub (May 15, 2021): > We already end up providing support for these packaged versions, annoying as that is. The only difference with this idea is that we control (and better understand) the environment they are run under. Or we simply provide them with zero support, which is perfectly valid. You can specifically say in bold print that you don't support the binaries you release but that will not stop people from demanding support. Even in that case prepare for a huge up-tick in noise.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 15, 2021):

What are you basing this assertion on? I distributed it as-as as part of a raspberry pi based image. I don't see why others wouldn't also do that. You'll be surprised how other people use things, it's just as often the opposite of what you think/intended!

Do you release it naked not wrapped in a service? Does the user have to specifically provide all the args and call it themselves or do you provide a config file with your own defaults?

@JasonLG1979 commented on GitHub (May 15, 2021): > What are you basing this assertion on? I distributed it as-as as part of a raspberry pi based image. I don't see why others wouldn't also do that. You'll be surprised how other people use things, it's just as often the opposite of what you think/intended! Do you release it naked not wrapped in a service? Does the user have to specifically provide all the args and call it themselves or do you provide a config file with your own defaults?

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@kingosticks commented on GitHub (May 15, 2021):

Just close them. Lock them and ignore them. If we need a issue template that makes that clearer then can do that also.

Sometimes the issues will be real, useful bug reports and sometimes they'll be useless crap from people who didn't bother reading the docs. Yes, it can take time to triage them, but for people that can't contribute directly to a rust codebase, sifting through those issues can be a valuable way to contribute. If in doubt, close the issue and direct them to a downstream project with better support. Providing binaries does not mean providing support. Most people appreciate that, for the few that get upset and confused about what we owe them (nothing) - that is their problem.

You might be able to tell, I've got zero time for people demanding things from open source projects. Starting with polite and progressing to ignore works well.

@kingosticks commented on GitHub (May 15, 2021): Just close them. Lock them and ignore them. If we need a issue template that makes that clearer then can do that also. Sometimes the issues will be real, useful bug reports and sometimes they'll be useless crap from people who didn't bother reading the docs. Yes, it can take time to triage them, but for people that can't contribute directly to a rust codebase, sifting through those issues can be a valuable way to contribute. If in doubt, close the issue and direct them to a downstream project with better support. Providing binaries does not mean providing support. Most people appreciate that, for the few that get upset and confused about what we owe them (nothing) - that is their problem. You might be able to tell, I've got zero time for people demanding things from open source projects. Starting with polite and progressing to ignore works well.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 15, 2021):

Just close them. Lock them and ignore them. If we need a issue template that makes that clearer then can do that also.

Still noise.

@JasonLG1979 commented on GitHub (May 15, 2021): > Just close them. Lock them and ignore them. If we need a issue template that makes that clearer then can do that also. Still noise.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 15, 2021):

It's really neither here nor there for me. I won't be spammed. You guys can do what you like.

@JasonLG1979 commented on GitHub (May 15, 2021): It's really neither here nor there for me. I won't be spammed. You guys can do what you like.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@MrksHfmn commented on GitHub (May 17, 2021):

spotifyd

Most people do not use librespot directly as-is, they use it as a lib, as is the case with spotifyd or as some sort of service or plugin. It makes a lot more sense for those projects to provide binaries/packages.

as a user i compile librespot myself and then run the binary on my home server. i connect it to the hd intel device (via --device) of the mainboard, then the audio system is attached to it. i don't use services like spotifyd or similar. pure librespot ... for compiling i have a debian vm incl. rust build system ... i think the vm is about 5 GB. after that i have a 13 MB binary

@MrksHfmn commented on GitHub (May 17, 2021): > spotifyd > Most people do not use librespot directly as-is, they use it as a lib, as is the case with spotifyd or as some sort of service or plugin. It makes a lot more sense for those projects to provide binaries/packages. as a user i compile librespot myself and then run the binary on my home server. i connect it to the hd intel device (via --device) of the mainboard, then the audio system is attached to it. i don't use services like spotifyd or similar. pure librespot ... for compiling i have a debian vm incl. rust build system ... i think the vm is about 5 GB. after that i have a 13 MB binary

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@Johannesd3 commented on GitHub (May 17, 2021):

PoC:
https://github.com/Johannesd3/librespot/actions/runs/850777993
https://github.com/Johannesd3/librespot/releases/tag/test-v0.0.1
github.com/Johannesd3/librespot@bf45bd3dee/.github/workflows/release.yml

@Johannesd3 commented on GitHub (May 17, 2021): PoC: https://github.com/Johannesd3/librespot/actions/runs/850777993 https://github.com/Johannesd3/librespot/releases/tag/test-v0.0.1 https://github.com/Johannesd3/librespot/blob/bf45bd3deed27c3caaf6548514fb97a63afc1792/.github/workflows/release.yml

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@roderickvd commented on GitHub (May 17, 2021):

Cool. Also know that moOde uses vanilla librespot and no spotifyd.

I'm going to submit a PR to remove support for libvorbis and tremor. That might make this a bit easier. Certainly if we'd then just compile in the "default" backends.

We'll have to do some thinking what's "default" for Linux -- just Rodio or also Alsa? And if we say yes to Alsa, then why not PulseAudio or GStreamer?

Here's one argument for doing Alsa but not the others: any modern Linux system with sound support will have libraries installed for Alsa but not necessarily for PulseAudio or GStreamer. Pervasive as they are on Linux desktops, they're not standard on headless Raspberry Pi boxes that I think are important targets.

Just doing Rodio might be easier, but misses out on easy opportunities for high-quality audio. Unless the DAC accepts F32 samples (and most don't), cpal will convert to S16 dropping dynamic range and without dithering.

As a workaround, the Alsa device could be setup as dmix which provides faux support for F32 but again convert down internally without dithering. This time conversion will be down to the highest quality audio format supported by the hardware, so at least it's better than cpal, but why bother when you could just use the Alsa backend directly?

@roderickvd commented on GitHub (May 17, 2021): Cool. Also know that moOde uses vanilla `librespot` and no `spotifyd`. I'm going to submit a PR to remove support for `libvorbis` and `tremor`. That might make this a bit easier. Certainly if we'd then just compile in the "default" backends. We'll have to do some thinking what's "default" for Linux -- just Rodio or also Alsa? And if we say yes to Alsa, then why not PulseAudio or GStreamer? Here's one argument for doing Alsa but not the others: any modern Linux system with sound support will have libraries installed for Alsa but not necessarily for PulseAudio or GStreamer. Pervasive as they are on Linux desktops, they're not standard on headless Raspberry Pi boxes that I think are important targets. Just doing Rodio might be easier, but misses out on easy opportunities for high-quality audio. Unless the DAC accepts `F32` samples (and most don't), cpal will convert to `S16` dropping dynamic range and without dithering. As a workaround, the Alsa device could be setup as `dmix` which provides faux support for `F32` but again convert down internally without dithering. This time conversion will be down to the highest quality audio format supported by the hardware, so at least it's better than cpal, but why bother when you could just use the Alsa backend directly?

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 17, 2021):

Here's one argument for doing Alsa but not the others: any modern Linux system with sound support will have libraries installed for Alsa but not necessarily for PulseAudio or GStreamer. Pervasive as they are on Linux desktops, they're not standard on headless Raspberry Pi boxes that I think are important targets.

Not to mention that both pulseaudio and pipewire both have ALSA compatibility plugins so that ALSA apps generally just work. I have 2 computers 1 running Fedora 34 with pipewire and 1 running Mint with pulseaudio. librespot compiled with just the ALSA backend works just fine on both.

@JasonLG1979 commented on GitHub (May 17, 2021): > Here's one argument for doing Alsa but not the others: any modern Linux system with sound support will have libraries installed for Alsa but not necessarily for PulseAudio or GStreamer. Pervasive as they are on Linux desktops, they're not standard on headless Raspberry Pi boxes that I think are important targets. Not to mention that both pulseaudio and pipewire both have ALSA compatibility plugins so that ALSA apps generally just work. I have 2 computers 1 running Fedora 34 with pipewire and 1 running Mint with pulseaudio. librespot compiled with just the ALSA backend works just fine on both.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 17, 2021):

As a workaround, the Alsa device could be setup as dmix which provides faux support for F32 but again convert down internally without dithering. This time conversion will be down to the highest quality audio format supported by the hardware, so at least it's better than cpal, but why bother when you could just use the Alsa backend directly?

Configuring librespot to the highest format your DAC will support and directly addressing your DAC bypassing dmix is always going to provide the most direct audio path and therefore the best sound quality. There's no reason to go though dmix in a purpose built audio distro other than the convenience of software mixing so you don't have to be 100% sure one service isn't trying to make noise before another gives up control of the DAC. librespot has blocking event script hooks that can be used avoid that situation.

@JasonLG1979 commented on GitHub (May 17, 2021): > As a workaround, the Alsa device could be setup as dmix which provides faux support for `F32` but again convert down internally without dithering. This time conversion will be down to the highest quality audio format supported by the hardware, so at least it's better than cpal, but why bother when you could just use the Alsa backend directly? Configuring `librespot` to the highest format your DAC will support and directly addressing your DAC bypassing `dmix` is always going to provide the most direct audio path and therefore the best sound quality. There's no reason to go though dmix in a purpose built audio distro other than the convenience of software mixing so you don't have to be 100% sure one service isn't trying to make noise before another gives up control of the DAC. `librespot` has blocking event script hooks that can be used avoid that situation.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@herrernst commented on GitHub (May 18, 2021):

Most people do not use librespot directly as-is, they use it as a lib, as is the case with spotifyd or as some sort of service or plugin. It makes a lot more sense for those projects to provide binaries/packages.

Are you sure? Because I also use librespot as-is, the binary does everything I need (and I always have the latest features). With the simple provided systemd unit it autostarts on boot and restarts on crashes and logs to journalctl. cargo deb even builds a nice debian package with the systemd unit (probably should be documented). I don't know what raspotify or spotifyd are good for (except maybe a config file, which I handle by systemctl edit).

Not sure we should provide precompiled binaries though. Savvy users can easily compile it themself, and others should use a package from their distro (or kodi plugin), not manually download some binary.

@herrernst commented on GitHub (May 18, 2021): > Most people do not use librespot directly as-is, they use it as a lib, as is the case with spotifyd or as some sort of service or plugin. It makes a lot more sense for those projects to provide binaries/packages. Are you sure? Because I also use librespot as-is, the binary does everything I need (and I always have the latest features). With the simple provided [systemd unit](https://github.com/librespot-org/librespot/blob/dev/contrib/librespot.service) it autostarts on boot and restarts on crashes and logs to journalctl. `cargo deb` even builds a nice debian package with the systemd unit (probably should be documented). I don't know what raspotify or spotifyd are good for (except maybe a config file, which I handle by `systemctl edit`). Not sure we should provide precompiled binaries though. Savvy users can easily compile it themself, and others should use a package from their distro (or kodi plugin), not manually download some binary.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@Johannesd3 commented on GitHub (May 18, 2021):

Repository	Stars on GitHub
Spotifyd	4,994
raspotify	3,216
librespot	2,241
ncspot	1,976

But raspotify is indeed librespot as-is. Spotifyd adds more cool stuff, but I don't know exactly what.

@Johannesd3 commented on GitHub (May 18, 2021): | Repository | Stars on GitHub | | - | - | | Spotifyd | 4,994 | | raspotify | 3,216 | | librespot | 2,241 | | ncspot | 1,976 | But raspotify is indeed librespot as-is. Spotifyd adds more cool stuff, but I don't know exactly what.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 18, 2021):

But raspotify is indeed librespot as-is. Spotifyd adds more cool stuff, but I don't know exactly what.

Yes the binary is pure librespot but it's compiled with only the alsa backend and configured to be a service made to work specifically on Raspberry Pi's (headless Pi's for the most part). It's a little bit more that than librespot as-is. It's basically Spotifyd "lite" for a Raspberry Pi.

@JasonLG1979 commented on GitHub (May 18, 2021): > But raspotify is indeed librespot as-is. Spotifyd adds more cool stuff, but I don't know exactly what. Yes the binary is pure `librespot` but it's compiled with only the alsa backend and configured to be a service made to work specifically on Raspberry Pi's (headless Pi's for the most part). It's a little bit more that than `librespot` as-is. It's basically Spotifyd "lite" for a Raspberry Pi.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 18, 2021):

I don't know what raspotify or spotifyd are good for (except maybe a config file, which I handle by systemctl edit).

I can't say about Spotifyd as I don't use it but as far as raspotify basically you hit one nail on the head. It has a config file which is easier for most people to edit and it keeps the unit file clean. The other being that raspotify gives you a repo so it gets updates via apt.

@JasonLG1979 commented on GitHub (May 18, 2021): > I don't know what raspotify or spotifyd are good for (except maybe a config file, which I handle by systemctl edit). I can't say about Spotifyd as I don't use it but as far as raspotify basically you hit one nail on the head. It has a config file which is easier for most people to edit and it keeps the unit file clean. The other being that raspotify gives you a repo so it gets updates via apt.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@herrernst commented on GitHub (May 18, 2021):

I don't know what raspotify or spotifyd are good for (except maybe a config file, which I handle by systemctl edit).

I can't say about Spotifyd as I don't use it but as far as raspotify basically you hit one nail on the head. It has a config file which is easier for most people to edit and it keeps the unit file clean. The other being that raspotify gives you a repo so it gets updates via apt.

Yeah, an apt repo is nice of course, and a nice config file is also good ;-)

@herrernst commented on GitHub (May 18, 2021): > > I don't know what raspotify or spotifyd are good for (except maybe a config file, which I handle by systemctl edit). > > I can't say about Spotifyd as I don't use it but as far as raspotify basically you hit one nail on the head. It has a config file which is easier for most people to edit and it keeps the unit file clean. The other being that raspotify gives you a repo so it gets updates via apt. Yeah, an apt repo is nice of course, and a nice config file is also good ;-)

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@JasonLG1979 commented on GitHub (May 18, 2021):

Yeah, an apt repo is nice of course, and a nice config file is also good ;-)

Generally I think raspotify does what downstream should do in relation to upstream. They take a program, compile it, package it up and put it in a repo to make it easier for average end users to install it, update it and use it. That's what should be encouraged. If your OS or distro or whatever doesn't package librespot IMHO users should ask them to. To me that's the natural order of things.

Advanced users are free ofc to compile and do with librespot basically what they wish. I don't really see releasing binaries being anything other than an added headache.

@JasonLG1979 commented on GitHub (May 18, 2021): > Yeah, an apt repo is nice of course, and a nice config file is also good ;-) Generally I think raspotify does what downstream should do in relation to upstream. They take a program, compile it, package it up and put it in a repo to make it easier for average end users to install it, update it and use it. That's what should be encouraged. If your OS or distro or whatever doesn't package librespot IMHO users should ask them to. To me that's the natural order of things. Advanced users are free ofc to compile and do with librespot basically what they wish. I don't really see releasing binaries being anything other than an added headache.

kerem commented

2026-02-27 19:30:26 +03:00

Author

Owner

@roderickvd commented on GitHub (Jan 12, 2022):

I'm with @JasonLG1979 here; closing.

@roderickvd commented on GitHub (Jan 12, 2022): I'm with @JasonLG1979 here; closing.

Rows
Columns

[GH-ISSUE #727] Release precompiled binaries #401