How to add github project to install list in SetupHelper

[ddarek2000]

I would like to add repository project to the SetupHelper.
Could you describe steps required to accomplish this , or point me to the documentation that contains the steps ?

example repository desired: https://github.com/Louisvdw/dbus-serialbattery

[kwindrem]

Right now the repo and user are hard coded to my packages. This is defined in UpdateResources and EssentialResources. About the only way for now would be to create your own SetupHelper

[ddarek2000]

I propose to move that information to the SetupHelper.conf file with one package per line. Modifying UpdateResources to loop through the lines and executing update. Default values should be specified during installation in SetupHelper.conf.orig which is copied when required SetupHelper.conf is not present, never overwritten.
Config file would have format allowing for comments :

# Comments ignored
kwindrem/SetupHelper:1.0
kwindrem/GuiMods2:latest
# kwindrem/RpiDisplaySetup:latest
Louisvdw/dbus-serialbattery:latest

If you set this as an enhancement , I will attempt some of this development.

[kwindrem]

I already have a place to store setup options for each package: /data/setupOptions, then a folder for each package. A file can be added to each package, created by the setup script for that package. SetupHelper would then read the file for GitHub info.

I prefer this rather than having user/version for each package in a common file. It's easier to update/modify.

[kwindrem]

Giving this some additional thought: There needs to be a place somewhere to include a list of packages that SetupHelper can manage. Right now, this information is hard coded into the installer portion of SetupHelper, but with others contributing to packages, management of this isn't all that simple.

Each package's setup script could add itself to a list kept in a file in /data so that any package installed would be in this list.

I also provide a mechanism to manually install packages from GitHub. But this requires knowledge of the projects. I might be able to add an option to specify a GitHub user and repo as part of that process. This makes things less automatic for unskilled users.

Any other ideas?

[kwindrem]

I'm liking your proposal more than something automatic. It does require editing the config file to add packages or to specify a version, but maybe those that would get to that level of detail can handle a text edit.

One thing that probably needs to be done is to add a new package to the config file automatically because the default config file would not get copied over if the working config file exists. I think this can be added to CommonResources in the same way I now add venus update reinstalls to /data/reinstallScriptsList.

[kwindrem]

Made progress today. I think it's working but give it a once over.

It's on the test branch and is version v3.1~1

The mechanism is basically as you proposed with a file that specifies packages, their GitHub user and the path or version within the repo. Note the package name and repo name need to match for this to work.

The file to edit to control updates is /data/setupOptions/SetupHelper/packageList. The default is defaultPackageList in the SetupHelper folder.

I have code to automatically add a package that isn't in the default list when the package is created. You just need to set packageGitHubUser and packageGitHubBranch in the package's setup script.

I did not add your package because it appears not to have a SetupHelper compatible setup script. If SetupHelper's update code doesn't find a setup script you will get an error but it may place the code in /data. I also noticed you don't have a version file. without that, I don't have anything to compare against the GitHub repo version and the install will most likely fail. Need to think more about this as there might be a better way.

[ddarek2000]

Very glad you found my suggestion useful. I will get version file included in the https://github.com/Louisvdw/dbus-serialbattery repository. What other requirements need to be met for SetupHelper compatible setup script ? I will make changes in my own fork repository and push the complete set once tested.

[kwindrem]

The version file will be essential. Without it, the automatic update logic can't tell whether or not an update is needed.

The version file is in the same format as Victron Venus: v2.5~3. I ignore the "large" portion of the Venus version string (which isn't part of the versioning system I use for my packages anyway). I use the ~ portion for development versions. A non ~ version is considered "later" than any with a ~.

The update mechanism expects a shell script or program named setup inside the package directory.

The updater runs setup after fetching the update. If reinstalling the package it passes "reinstall" and "force" on the command line. If running manually (from packageUpdater) it passes "deferReboot".

Packages will be reinstalled following a Venus OS update. This reinstall mechanism will run the same setup script/app and pass "reinstall".

The setup script will test an "installed flag file" in /etc/venus. If present, the reinstall mechanism will not rerun the reinstall.

If no setup script/app is present, the installer will log an error, but at this point you'll have the package installed in /data.

What you do inside the setup program/script will depend on your package. It's intended to move pieces of the package into the active areas of the file system. SetupHelper also provides some utilities to make common tasks simpler but you don't need to use any of the "CommonResources" functionality. But if you do not, there are things you need to handle yourself. One is adding the package to the list for Venus OS update reinstalls. Another is adding the package to the packageList file. Most of this is handled in the endScrpit function in CommonResources. If you use the reinstall mechanism, I highly recommend you use CommonResources in your setup script because so much is handled for you.

Take a look at any of my packages to see what functionality is present and how to use CommonResources. There is also a sample setup script in SetupHelper's directory that may help.

[kwindrem]

I'm moving the packageList file from /data/setupOptions/SetupHelper to /data to make it easier to find and access for manual changes. /data/setupOptions/SetupHelper.

SetupHelper's setup script will move the file if it already exists in the current location.

[kwindrem]

One additional thing: SetupHelper resources will create a version setting for any package, however display on the Settings/Display & Language/GuiMods/Packages page requires modifying the QML code to add display for each specific package. I'm not crazy about modifying GuiMods to add versions for other people's packages and this lessens the utility of the file-based package list.

Ideas welcomed.

[ddarek2000]

QML code would have to be created dynamically when update happens, or when check for new version is performed.

[kwindrem]

I've been in the process of rewriting SetupHelper to make adding other packages to the system fairly easy without the need to edit any config files.
The user interfaces to a new mechanism I call PackageManager via a series of menus. From there you can look to see which packages are known to the system, remove packages, add packages, download from GitHub and install/uninstall the package.
Adding a package consists only of entering the package name and GitHub information for automatic downloads.

Packages must contain a version file as I described previously and for automatic and manual installation (an uninstall) needs a script or program called setup in the package directory. What setup does is up to the package designer but needs to return status to PackageManager via return codes so the latter knows of success or the reason for failure.

I also scan SD/USB media for possible packages (.tar.gz archives) and transfer them to local storage in /data. From there, PackageManager can automatically install them (or manually) if they meet the criteria mentioned above.

This project has been a couple months in the making but after a few more days of testing, I should be ready for some beta testing.
One thing that remains is to update the ReadMe, and possibly creating a better document describing the package, how to use the GUI interface and how to build packages that PackageManager and SetupHelper can deal with.

Let me know if you are interested in testing.

Here a some screen shots of the U/I

[claib]

hi there, and super thanks for the brilliant work !
Where are we at the moment with the new version for Venus 2.9x ?
best regards !

[kwindrem]

Not sure what you mean. SetupHelper is compatible with Venus v2.9x. In fact the latest version of SetupHelper no longer had any version-dependent files so there should be minimal compatibility issues moving forward.

[claib]

i mean the capacity to integrate / maintain scrips like the often used dbus script :
https://github.com/Louisvdw/dbus-serialbattery

[kwindrem]

There is a document included with SetupHelper to aid in creating your own packages. I’m also available to help if problems develop. Once the package is done, you can easily add it to the active packages list.

[claib]

because the Louisvdw script is probably one of the most uses and useful scripts, it would be genious to have it integrated.
may i ask you gently ?

[kwindrem]

The designer of the driver you reference would need to build this into a package to take advantage of SetupHelper. It would be far too much effort for me to convert every such Venus OS enhancement to work with SetupHelper/PackageManger. Sorry.

[freakent]

Where do I find the document "Package development guidelines"? I am the author of dbus-mqtt-devices and I'm interested in enabling install via the package manager.

No matter I found it in the project :-)

[kwindrem]

It is in the SetupHelper repo. A PDF file