Feature Request: CLI Based In-Place Upgrade

[macr0dev]

Request ability to do in place upgrade from the CLI. Would be best if it didn't require any interaction so that it could be run scripted.

[Mbucari]

So this one is tricky. First of all, a cli program should not have a GUI updater. If we can all agree to that, then we can move on to discussing the challenges of updating from the terminal.

Challenges:

In addition to the normal challenges of an app updating itself, there are some cli-only issues.

How do you show the user progress?

You can show progress of downloading the update package if libationcli is doing the downloading, but libationcli must exit before it can run the updater. But once the cli program exits it can no longer write anything to standard output, and the terminal doesn't know about the spawned updater process, so it won't be reading its standard output. I see three approaches to deal with this

1. Don't worry about it

Just let the updater run and hope the user doesn't re-start libationcli before updating is complete. This is not a good solution because if libation is run before updating is finished, it could brick the installation.

2. Delete libationCli.exe before launching the updater

instead of libationcli running the updater and exiting, it starts a different program that deletes libationcli.exe before running the updater. That way libationcli is unavailable until it is extracted from the update package. The problems with this approach are

1. LibationCli.exe may be extracted and executed before the update package has finished extracting, which could brick the install
2. the user still isn't notified that the install has completed, or of any errors.

3. Libation creates a update script and asks the user to run it

After downloading the update package, libationcli writes a simple update script to the program files directory. The user can run this script, monitor the update progress, and see when it completes or if any errors were encountered. This will work because, as far as I know, no OS locks a script file while it's executing, so it can be overwritten/deleted on disk while it is executing.

Obviously I think this is the way to go.

What program do we use to do the updating?

We have AutoUpdater.Net for the windows gui releases, but those will not work for Linux or the cli. I think we can copy the guts of ZipExtractor.exe into a console app to solve the windows cli problem, and I think that whatever solution we find for linux can work for both the gui and cli.

[cregkly]

Easiest option here is to just run in a docker container and pull a new docker image to upgrade.

[Mbucari]

@rmcrackan It's funny that for once, this feature request is trivial to implement on *nix but a real problem on Windows.

[CharlieRussel]

Powershell? Says the former Powershell geek, I admit, but given that it runs in all three OS's, and uses .NET underneath, seems like it might be an option...

[Mbucari]

@CharlieRussel I am very much not a powershell geek, but doesn't Windows have a default security policy that disallows executing powershell script files? How would we make that work for your standard Windows Home version non-power users?

Edit* what am I saying? Nonpower users aren't upgrading via command line.

[CharlieRussel]

@Mbucari -- Yes, it does (sort of), and yes, it's not something a non-poweruser will encounter. However, there are workarounds for not allowing the script to execute. You can:

• sign the script (this will work for most default setups which are set to RemoteSigned)
• you can prompt the user to allow you to change the execution policy (for that session ONLY)
• you can bypass the execution policy (if there is no returned output)

A useful Q&D explanation can be found here.

[rmcrackan]

How much of this could be solved with a mutex? They're kinda expensive but are probably worth it here for the safety

[Mbucari]

How much of this could be solved with a mutex?

We can use a mutex to signal the updater that libationcli has closed. Libationcli itself could also be the updater program, waiting for the mutex to be released and then extracting the contents to the program files folder.

My problem with that is there's still no way to notify the user that the process has completed. Once libationcli exits, there's no way to write to the console's stdout. For this reason, I'm leaning towards @CharlieRussel's suggesting of creating an update script and having libationcli print out the command to run to execute it. The update script will inform the user when it's completed.

[wtanksleyjr]

This all seems to make a decent argument for better support for docker-compose; at least docker-compose has built-in support for updating (docker-compose pull; docker-compose up -d), although you actually have to run the command (you can't update a container from inside the container) it can be automated.

I'm having nightmares with docker networks right now, I never really bothered to learn anything more than just pasting services together into a docker-compose.yml. So easy. Add in networks and apparently all of the good feelings are gone.

-Wm

On Tue, Mar 14, 2023 at 1:39 PM Mbucari @.***> wrote:

How much of this could be solved with a mutex?

We can use a mutex to signal the updater that libationcli has closed. Libationcli itself could also be the updater program, waiting for the mutex to be released and then extracting the contents to the program files folder.

My problem with that is there's still no way to notify the user that the process has completed. Once libationcli exits, there's no way to write to the console's stdout. For this reason, I'm leaning towards @CharlieRussel https://github.com/CharlieRussel's suggesting of creating an update script and having libationcli print out the command to run to execute it. The update script will inform the user when it's completed.

— Reply to this email directly, view it on GitHub https://github.com/rmcrackan/Libation/issues/326#issuecomment-1468808127, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ7H6OC7NM7WVQWKTYFRDTW4DJRXANCNFSM54ZVJ6DA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[rmcrackan]

This ticket is about to have it 1 year anniversary. Are we ready to call it 'unresolvable'?

[CharlieRussel]

How about something like Chocolatey?

[macr0dev]

I know I'm the person that started this particular party, but I'm looking at migrating it into my docker setup instead of running it on my Windows box.

I know the notes say it's "as-is" and "not supported" - but if it works well enough, it's good enough for me. Lord know most of us are kludging stuff together at our houses anyway, but I'm already using watchtower to check for container updates every night.

[CLHatch]

How about something like Chocolatey?

Yes, I was wondering if it could be made installable using Winget, Chocolatey and/or Scoop. I was using Chocolatey before, but I now use Winget when possible, and Chocolatay if the app I want isn't available in Winget. Not gotten around to trying out Scoop.

[wtanksleyjr]

I'd think we're closer than we were before to having Docker... Specifically, when the dpkg setup runs it gives you a plausible set of startup options in a good location. We could zip those up and include a docker-compose override file pointing to those, so you can pretty much just unzip them in the same folder as your existing docker-compose and then edit the file before "docker-compose up" it.

I don't want cron jobs running inside Docker where I can't change them, I want all that to be controlled from my own platform. At least put the crontab in the zip file and make it part of the external config so I can customize it.

Hm. I need to see if I can read the docker source files now, I couldn't figure them out before and maybe I've learned enough.

On Thu, Jul 13, 2023 at 8:09 AM macr0dev @.***> wrote:

I know I'm the person that started this particular party, but I'm looking at migrating it into my docker setup instead of running it on my Windows box.

I know the notes say it's "as-is" and "not supported" - but if it works well enough, it's good enough for me. Lord know most of us are kludging stuff together at our houses anyway, but I'm already using watchtower to check for container updates every night.

— Reply to this email directly, view it on GitHub https://github.com/rmcrackan/Libation/issues/326#issuecomment-1634420343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ7H6LEKNBMXRVEPPU4NHTXQAFT3ANCNFSM54ZVJ6DA . You are receiving this because you commented.Message ID: @.***>

[CLHatch]

I just discovered that Winget now supports extracting zip files for installation, so we should be able to get Libation into the Winget repo now. I would think we would need to have two manifests submitted, one for the "Classic" variant and one for the the "Chardonnay/Avalonia" variant. I'm betting there's a way to build the submission of manifests into the release scripts also?

[RokeJulianLockhart]

https://github.com/rmcrackan/Libation/issues/326#issuecomment-1634519607

I was wondering if it could be made installable using Winget

https://github.com/microsoft/winget-pkgs/issues/120820#issue-1912285752

[Dragon1573]

I just discovered that Winget now supports extracting zip files for installation, so we should be able to get Libation into the Winget repo now.

@CLHatch NO, NEVER for the current Windows release type of Libation.

Winget DOES support zip files as installer, BUT the zip file should only contain executable as following types:

• One or more nested *.appx / *.msix / *.msi / *.exe installation wizard, each file is a standalone wizard. See https://github.com/microsoft/winget-pkgs/pull/121750
• One or more *.exe portable executable, each file is a standalone executable containing all necessary libraries (Or its dependencies can be installed by Winget too). See https://github.com/microsoft/winget-pkgs/pull/122214

classic.zip and chardonnay.zip both contain plenties of *.dll libraries for the main *.exe executable. Winget regard these kind of application as "loose executable", which is not supported at the moment (stable version v1.6).

If further version of Libation can switch to MSI/MSIX installer file or EXE installer wizard packaged by well-known creator (such as InnoSetup, Wix, NullSoft), I will glad to create a manifest for it.

---

@RokeJulianLockhart Sorry, we can't achieve https://github.com/microsoft/winget-pkgs/issues/120820 .

[rmcrackan]

I think it's fair to say that if we haven't figured this out in the last 2 years, this ain't happening