Chocolatey is a very useful tool for installation and is referenced in the installation documents, but will not install 2.0.6.3 using the Upgrade command.
I am assuming this is because it is still marked as in Beta (though I thought it all was).
However, the Duplicati interface constantly tells me to upgrade to 2.0.6.3 from 2.0.5.1
It seems to me that either we need to allow Chocolatey to upgrade to 2.0.6.3 using “choco upgrade duplicati”, or we need to change the Update Channel settings to allow only notifications on the latest “chocolatey-acceptable” build.
https://community.chocolatey.org/packages
search for duplicati finds 2.0.3.3 and 2.0.5.1 even though selector says “Stable only”.
Changing filter selector to “Include Prerelease” has just 2.0.6.104 (the latest Canary).
This means that they seem to have some awareness of the Duplicati channel layout.
You probably meant 2.0.6.3, which is the current Beta. 2.0.5.1 was the previous Beta.
Duplicati neither prevents it nor provides it. Chocolatey is an independent organization.
The update channel is a Duplicati feature tracking its releases. It can’t track everybody.
The best way to stay current is to ask (however it’s done) for Chocolatey to get 2.0.6.3.
Request Package Fixes/Updates might have ways, but please investigate this yourself.
Back to Duplicati behavior, is there a reason you won’t let the Duplicati updater update?
It’s possible (but awkward, and maybe rather bad practice) to turn off its update notifier.
Thank you for the correction on the version number. You are absolutely correct, I just had it in my head wrong. 
Why this matters overall:
Chocolatey is a distribution method that is referred to in the Duplicati install documentation not as an unsupported method, but as a prime method of installation.
If that is true, then it should match the requests for upgrades from within the program (also a primary distribution method).
Why this matters to me personally:
I am managing hundreds of computers, many of which run Duplicati, all of which run Chocolatey. Updating them manually is an expenditure of time that I would rather not spend unless absolutely necessary. However, since every end user that wants to go look is able to see that there is an “error message” (I know it’s not, and you know it’s not… but they have been educated to the need of keeping systems upgraded, and here is a glaring message telling them that it isn’t upgraded). That perception issue can reflect badly on me for installing software that I am not keeping “up to date”.
Principle:
If there are reasons to ask that the client be upgraded from within Duplicati, when the least upgrade settings are selected (currently beta), then there are reasons to upgrade the Chocolatey distribution method to match.
If this doesn’t work as it sits then there needs to be a lower update setting in Duplicati - maybe called “Stable” or “Stable Chocolatey” - that is kept in sync with the Chocolatey distribution method. This would keep the software and the distribution method in sync.
Since Chocolatey relies on community members to maintain each package distribution, and since Duplicati lists it as a primary installation source, it seems logical that someone on the Duplicati team is a maintainer of the Chocolatey package distribution. This input was directed at them. I have already posted on the Chocolatey Distribution Package Discussion requesting an update, but since I was not alone, I thought maybe I should bring the discussion here.
In the locus of power model, since Chocolatey is only a redistribution method and couldn’t care less if any single package is maintained, the real beneficiary is the Duplicati team that wants to maintain channels of distribution in coordination with those in their direct control (website & internal update). So this discussion placed here makes the most sense. If you are the Chocolatey Package Maintainer for Duplicati (dtgm, bcurran3 or afischer211), then this is for you. If you are the team member in charge of considering the channels of update within the Duplicati project, then this is for you.
I can’t find that page. It’s not in the manual at Installation (that I see). Got a link? Maybe it needs a fix.
I Google searched site github.com/duplicati, www.duplicati.com, and forum.duplicati.com.
Truth also varies with time. You can see that Chocolatey does supply old versions but not new ones.
If the connection with Chocolately (that I can’t find) is overboard for current, maybe it can be lowered.
I would prefer, though, that they stay current. Duplicati team has no control over that though AFAIK…
I disagree. Update channels are independent. Each distributor uses its own way of providing updates.
Duplicati has one, Chocolatey has one. Do you know if Chocolatey even has an API for coordination?
Running the Chocolatey search doesn’t really count IMO. How could one achieve the ideal you wish?
It would also seem like Duplicati would have to know how it was installed. I definitely wouldn’t want to
prevent updates for all Duplicati systems just because one packager (e.g. Chocolatey) isn’t updating.
In upstream/downstream terms, Duplicati is upstream. Downstream should be picking up its updates.
The timeliness and mechanism that downstream packagers use is up to them (and user requests…).
I don’t use Chocolatey, but are you using some scripting to run choco to keep the packages current?
Although there could be a need for software restart, could you run Duplicati.Library.AutoUpdater.exe?
Duplicati autoupdates go into a separate folder to be found. Only .msi installs change Program Files.
I strongly suspect Chocolatey is based on .msi. If you know technical details, feel free to post details.
Chocolatey update will probably face the same problem all updates of running software does. Restart.
As a side note, the GUI button on Duplicati doesn’t always restart right. Sometimes it needs a manual.
You’re losing me there. Duplicati doesn’t create the Chocolatey distribution method. Chocolatey does.
If you meant get Chocolatey current (thereby solving your issue), you could try asking them, as noted.
https://forum.duplicati.com/u search for those three users says they’re not here, although names can
vary from community to community. You might get lucky, but you might also be asking in wrong place.
Is there a link to that, open to the public? This also isn’t what Package is Outdated? seems to suggest.
You might reach the maintainers more effectively with the “Contact Maintainers” button they say to use.
They give an escalation path if the maintainers don’t respond. Only Chocolatey can update Chocolatey.
I appreciate your well-articulated response.
I have to apologize for working from a memory that had Chocolatey as a primary installation resource. If that was true at one time, it no longer is. Chocolatey is clearly absent on the download page.
All other thoughts and recommendations were based on that premise. It appears to be a false premise, therefore negating everything else.
For your information (because you have been so kind as to take the time to dive deeply with me), I do use Chocolatey for keeping software up to date. I am not a package maintainer, so I cannot speak to the exact mechanism to calling script A for install, B for uninstall, and C for an upgrade, but I have to imagine it is similar to others that I have used. The installers themselves can be an MSI, but are most often just an executable with silent install features. There are lots of installation packages that use different engines. Some are straight batch files that move files around. I only know this as I watch the scripts running and can see the locations and files being called.
Thank you for your time, I value it and will waste no more of it.
Sincerely,
|<
The CLI upgrade mechanism is: run the mentioned Duplicati.Library.AutuUpdater.exe program.
If you run scripts on user systems (how do you run choco?), this is another run. If you don’t, then oops.
You’ll probably have to see if you can get Chocolatey maintainer to update, or you could offer it to them.
If you do have a script capability, you could maybe solve the restart problem with Duplicati as a service, although it would need to be tested, e.g. what if you restart the service while Duplicati is in mid-backup?
Command-line (including Duplicati.CommandLine.exe updates without a conflict. It’s designed that way.
Duplicati web UI is similar, although the design relies on the user to push a button at some suitable time.
Updating underneath a running server is kind of awkward, but Duplicati does support scripting options to
possibly do strange things like arrange for its restart in a run-after script, when the backup is not running.
Clicking “Package Source” for the 2.0.5.1 listing gave some of the who/when/how of Duplicati packaging.
Chocolatey has documentation on creating packages, and maybe you can follow that, if nobody else will.