headphones says updates is availble, but its not updated in synology

[xpunkt]

so i think headphones should have update disabled in synology repo, but added more updates to repo, so less bugs are longstanding problems to get solved

it would aswell help if the installer defined more paths default defined, its when edit config from headphone config webui hard to know what dirs is used in synology for storing data used in headphones

or if possible make that upstream to make that in headphones supporting synology configureing more easy

all that sayed i am happy with headphone as is, but i think we need to make it better still

[Dr-Bean]

I'm sorry, but I'm having a hard time understanding your text. Did you mean to open this issue on the Headphones repository maybe?

The update functionality is enabled in our package, in order to decrease the effort needed on our part for publishing a new package every time a commit is made upstream (hey, bugfix or feature was released, I want it, please publish a new package). Seeing as the functionality works fine, why would we want to disable it?

the installer defined more paths default defined

Please provide more details, I don't know what this means. If you want the Headphones interface to show where its config is located, please ask the maintainer of Headphones to build in that functionality (or create a PR for it). For the record, all the config/logs/whatnot are located in /usr/local/headphones/var.

[xpunkt]

problem as is, is that if updated from the web, what would happen if synology repo update (it could aktuly here downgrade) ?

i think that it should not be updated outside of synology in this regard, this is the same with gentoo portage i never just update anything outside of portage, for me if portage is missing anything i make a ebuild to install this software, so it is in portage and make sure md5 sums and collisons test is done to make sure no files is not overrided

[Dr-Bean]

I don't think I see a problem. For any other type of package, yes, we work with pinned versions and checksums to be able to reliably reproduce builds. However, for this type of package, we consider the packaged software separate from the package as such, and allow upstream to decide that when something is pushed to their master branch, that it's stable enough for our users.

As for package updates: when we update the Headphones package, we update it to the latest version automatically: Spksrc clones the repository during package creation. That's a tiny, tiny window of opportunity for something to go wrong: we update the package, a commit is pushed to the HP repo, you upgrade HP from the interface, and only then install the package upgrade. Even if that would happen, you'd immediately be offered the last commit(s) via the Headphones interface again.

But if you're worried something might happen, then you have several options:

• Don't upgrade via the webinterface. It doesn't happen automatically, you have to actually click a button. That does mean someone (you?) will have to start actively maintaining the package in spksrc, and keep it in sync with upstream. I don't mind that, but I don't think we'll disallow updating via the interface even then.
• Use the Headphones-Custom package. When we release package upgrades, we don't touch the local Headphones code at all. Then you can update via the webinterface whenever you feel like it. It's the exact opposite of what you're asking, but it has a similar result.
• Local installation, and clone whenever you want to upgrade.

For the record, Headphones is not the only package of this type. We allow updating for a number of packages, such as Couchpotato, HTPCManager, Jackett, Maraschino, NZBMegasearch, Sick*and Sonarr, and this has never caused any issues. We probably saw more issues being opened when auto-updating was not enabled...

[Dr-Bean]

Closing. Unless there are compelling reasons to turn off built-in updaters, we prefer to allow people to choose how/when to update -- limited to a certain type of package, e.g. the ones I mentioned in my previous comment.

Apart from that, we (maintainers/contributors/community members in general) can update the package, and we probably should do so regularly...but that means someone has to put in the effort, and open a PR.