New scriptAction value GUI_INSTALL

[herrfrei]

I'd like to detect if installation is started from command line or GUI.

Background: For GUI install, default values should be applied while on command line the user is asked for values.

[kwindrem]

Same response as provided in your duplicate post in RpiDisplaySetup:

SetupHelper differentiates between an install and a reinstall. When the script is run from the command line with no options, a menu of choices is presented. One if these options is reinstall which will use the existing options set in a previous run. If the options have not been set then the reinstall option does not apply.

When reinstallMods or PackageManager calls the setup script is includes 'reinstall' or 'install' or 'uninstall' on the command line. This causes SetupHelper to skip the user prompting. If options have been set (or are not required) then setup proceeds, otherwise the setup script exits without installing.

Are you creating a package? If so, let me know if I can help.

If you are just trying to reinstall the package from the command line, then including install on the command line will skip the prompting, or you can select reinstall (r) at the prompt.

[herrfrei]

Hi, sorry for the double-posting. Initially I entered it at the display repository since my package was inspired by that. But the problem is really for SetupHelper...

I created a display package for a HDMI capacitive touchscreen device that I modified to switch the backlight on / off via a GPIO pin. That's why I created this package (https://github.com/herrfrei/VeTouchDisplay). I wanted to have default values (no rotation, GPIO pin 23) without the need for user interaction when installing via PackageManager. Please take a look at the setup file!

For the default values no options are saved - is this a problem when the package should be reinstalled on a new OS version?

Btw. I added a workflow file to automatically assign the latest tag when a new release is created. May be this is of interest for you.

[kwindrem]

Your script should work for reinstall. You did not include the optionsRequired flag file in your package so CommonResorces will ignore the fact that /setupOptions/VeTouchDisplay/optionsSet does not exist.

[herrfrei]

Thanks for the review, @kwindrem! That looks good to me now.

Another thing is that I have a package for a combined CAN+RS485 HAT that modifies the gpio_list file (VeWsCan485). Since this file is also modified by various other packages (such as RpiGpioSetup), do we need something like an incompatible_packages file in the repos? Where we enter the packages that collide? I'm thinking of a message to the user that lists only the potentially colliding packages and then stops the installation. The user is responsible for handling the collisions manually.

[kwindrem]

I am interested in your workflow. I'm know of the workflow mechanism but not sure how it works and not at all familiar with yml.

When I create a new release, I will also manually remove latest release then tag then create the new latest release. Is this what your workflow does?

I'm assuming that I need to add this to all of my packages?

[kwindrem]

Regarding incompatible_packages:

I do think something like this is necessary as more people start modifying Venus OS. I'm not sure how to manage this however. It seems like someone would need to collect all packages that SetupHelper could install then compare all files found in the setup scripts.

One of the things that I was planning on doing is to have SetupHelper build a list of files a package modifies using updateActiveFile. This would most likely be 90% of the files modified. However there are some that are edited in-line in the setup script. One obvious example is /u-boot/config.txt for Raspberry PI platforms. With a list of modified files, it would be less of a task to search other package'smodifiedFiles list to identify conflicts. But it would slow install operations significantly.

Let's continue this discussion.

[herrfrei]

I am interested in your workflow. I'm know of the workflow mechanism but not sure how it works and not at all familiar with yml.

When I create a new release, I will also manually remove latest release then tag then create the new latest release. Is this what your workflow does?

I'm assuming that I need to add this to all of my packages?

Yes, you need to copy the workflow file into the same directory .github/workflows. And allow that workflows change the repo:

In each repo Settings >Actions > General > Workflow permissions check Read and write permissions.

That should trigger the latest tag regeneration when you add a new release. No more manual modifications.

[kwindrem]

Your automatic latest tag update works great. Thanks. One issue is when I manually generate the tag, the description from the push is added to the tag. This is not happening why the autogenerated latest tag.

I see a line in the .yml file for description. Can this be changed or if eliminated restore my previous behavior?

[kwindrem]

disregard my question. I removed the use: and description lines and the latest ended up with the description from the push.

[herrfrei]

I'll close this issue.

[kwindrem]

Just a heads up: SetupHelper v7.0 adds conflict detection and resolution based on a packageDependency file in a package's directory and also by checking which package installed each file. This is done on the GX device itself and will block an install until the conflicts are resolved. I have even provided a way to resolve the conflicts by installing (or installing) packages that conflict with the selected one.

This doesn't address the issue of two packages needing to modify the same file but does identify the conflict.