search

Botspot / vdesktop

Run a second instance of Raspbian inside Raspbian.
GNU General Public License v3.0
125 stars 21 forks source link

Remove auto-upgrade logic #16

Closed mtlynch closed 3 years ago

mtlynch commented 3 years ago

This functionality breaks existing scripts.

I use vdesktop as part of an automated taskflow. When vdesktop prompts for an upgrade answer, it breaks the workflow. This is unexpected, as a script that worked on Monday shouldn't suddenly break on Tuesday because of a change on a remote Github server.

Additionally, the previous implementation wasn't very safe. If the user had locally modified files in their repository, vdesktop would blindly erase them without prompting for confirmation.

Instead of attempting an auto-upgrade, this makes vdesktop simply print upgrade instructions.

Botspot commented 3 years ago

Oh I see what's going on: That automatic update-detection code has been there all along, but by bumping the version file your script gets stuck. Looks good to me.

Botspot commented 3 years ago

Just be aware that there is more interactive questions within vdesktop besides this one.

mtlynch commented 3 years ago

But they won't spontaneously pop up, right?

Interactive is fine as long as previously non-interactive code paths don't suddenly become interactive.

Botspot commented 3 years ago

There are two remaining lines that may ask a question if conditions are met. One will ask if you want to change the img's UUID. The other asks if you want dependency packages installed. Both questions, in addition to the update question you had me remove, have been there for nearly as long as vdesktop has been around.

mtlynch commented 3 years ago

Oh, those are fine for my use-case. I never exercise the code path in (1), and (2) won't appear unless I change the installed packages on the system.

Botspot commented 3 years ago

Within the next few weeks, I plan to do a major vdesktop rewrite, with some extra features such as HW acceleration, Chromium Aw Snap fix, and some other stuff. In theory, none of these changes should interfere with your script implementation, but I wouldn't want your setup broken again. So, would you rather just not ever update? Or would it be a better plan if I created a separate branch meant for script usage?

mtlynch commented 3 years ago

I currently use my own fork, but I'd like to get back in sync with your branch. The only differences in my branch are that I removed the sleep infinity and took out the shadow stuff.

We're not that far apart in functionality, so it would be great if script usage was just a matter of a particular command-line flag rather than its whole separate branch.

Breaking changes shouldn't be a problem for your users as long as you announce them in the release changelog. If you say, "v16 breaks legacy cli-login behavior," then I know not to update to v16 until I rewrite my scripts.

Botspot commented 3 years ago

Speaking of the sleep infinity, I've added that as an option in the config file. If line 5 is set to 'yes', then vdesktop will exit automatically after the machine exits.

Additionally, the previous implementation wasn't very safe. If the user had locally modified files in their repository, vdesktop would blindly erase them without prompting for confirmation.

Actually, vdesktop would move the old folder to ~/vdesktop.old.

Botspot commented 3 years ago

For shadow, you should just be able to delete the file.

mtlynch commented 3 years ago

Speaking of the sleep infinity, I've added that as an option in the config file. If line 5 is set to 'yes', then vdesktop will exit automatically after the machine exits.

Oh, nice! I'll try that out.

For shadow, you should just be able to delete the file.

I'd like to find a way for us to find a way of achieving the same thing without having to change a file under source control. Deleting shadow creates a change to the Git-monitored files, so it's essentially like having a separate fork.

Botspot commented 3 years ago

Adding a script mode setting to the config file would be no problem, but I am a bit confused: Doesn't editing the config file create a change to the Git-monitored files anyway? Either we can delete shadow and git will notice, or modify a line in config, and git will notice. I don't see any difference between the two.

mtlynch commented 3 years ago

Doesn't editing the config file create a change to the Git-monitored files anyway? Either we can delete shadow and git will notice, or modify a line in config, and git will notice. I don't see any difference between the two.

Yeah, it would be beneficial to solve both. I filed #18 to discuss options.