Implement Self-Update parameter/functionality

[lareq]

#made from wish list
check if newer version exists and replaces executable require parameter -c or --check-version
declared with REPOSITORY

changed system variables call from /etc/openwrt_release to /etc/os-release which is more "linux like"
ROUTER_NAME > HOSTNAME
DISTRIB_ARCH > OPENWRT_ARCH
DISTRIB_TARGET > OPENWRT_BOARD
DISTRIB_DESCRIPTION > OPENWRT_RELEASE
NAME - to be used in reports (future)

[tavinus]

Hi. This is interesting.

First question is if changing from /etc/openwrt_release to /etc/os-release will change anything.
Will it be exactly the same info in the reports or is anything gonna be different?

The upgrader logic seems ok, but it only checks if the version is the same. I have functions to check if version is bigger/smaller in other scripts. They also use the tarball, instead of the raw file (in case future versions have extra files). I may want to rename the parameter as well, probably --self-upgrade (not sure if with or without short option). The help info is a bit confusing. Mainly because we also have --upgrade-check. Anyways, need to make clear we are talking about upgrading itself from master, not upgrading opkg packages or checking them.

Here is how it is done in pdfscale, both the install and upgrade functions.
https://github.com/tavinus/pdfScale/blob/master/pdfScale.sh#L684
It is a bit complex if compared to this. I do like having all the checks and prompts though, since installing/upgrading will add/remove files on disk. That is BASH though, will need to check/adapt to ASH.

Then there is also the parameters to ignore SSL certificates and to force-confirm prompts.

Having --self-install is also interesting for many reasons, including to install directly from the web (one-liners).

About the parsing of blacklisted packages, there are many options. Complex parsing is mostly done with AWK here in opkg-upgrade. We could just save a package per line in the file. Should be easy to parse that.

[tavinus]

This is from the help of pdfscale:

 --install, --self-install [target-path]
             Install itself to [target-path] or /usr/local/bin/pdfscale if not specified
             Should contain the full path with the desired executable name
 --upgrade, --self-upgrade
             Upgrades itself in-place (same path/name of the pdfScale.sh caller)
             Downloads the master branch tarball and tries to self-upgrade
 --insecure, --no-check-certificate
             Use curl/wget without SSL library support
 --yes, --assume-yes
             Will answer yes to any prompt on install or upgrade, use with care

I would probably just remove the --upgrade option to avoid confusion and leave --sef-upgrade.
I remember there is also a readlink Bash implementation I had to do in order fix it in MacOS, but I am not sure about that in OpenWrt. I guess it is GNU and should be fine, but I am not sure it comes pre-installed in all systems.

[tavinus]

BTW

Both the installer and the upgrader can certainly be simplified a lot just by assuming/ensuring that we are running as root.

So we can basically make a single check if we are root and exit if it is not. Then we can remove all the checks and sudo parts. Would just run and check once. This removes 70% of the complexity of the pdfscale installers.

About using the raw version or the tarball, still not sure here. It may be easier/better to just use the raw in this case, since opewrt devices may be very uncappable machines.

[lareq]

/etc/os-release has same data, but has more informations and is platform independent (checked few opkg distributions for that). this is the only one reason to use it.
-self-upgrade looks much better.