Error if unsupported version in toltecctl

[Eeems]

Fix #445

[Eeems]

This is currently untested

[Eeems]

Did some spot testing on my rM1 and the code seems sound. I haven't tested by updating to the latest OS though.

[Eeems]

This will need to be updated when #579 is merged.

[Eeems]

Just tested and this seems to work properly. The values are for the latest stable as we'll be adding support for it with the other changes on their way into testing.

[matteodelabre]

Thanks for your work on this, Eeems! Haven’t tested this yet but judging by the diff this looks good.

Only thing is, I’m not sure hardcoding the supported version numbers in the script itself is a viable solution. Consider the following situation: someone upgrades to the latest OS release while Toltec doesn’t yet support it, so toltecctl reenable fails (as it should). But then, what happens? The toltec-bootstrap package would never be updated since reenable is failing, so the supported version numbers in the script would never be updated.

What about instead publishing two files on our website that would contain the latest supported version numbers? The script could pull those files and compare their value against the current /etc/version to decide whether to reenable.

Also, I’m not sure I understand the rationale for running check-version in the toltecctl switch-branch subcommand. Did you mean to add it to another part of the script?

[Eeems]

Technically they would still be able to install by using --force on the reenable. Fair point though, we should check something to see if the supported version has changed. How do you want to keep track of that?

I've seen some people running switch branch without understanding what it actually does already. We probably should include a version check there still, but only if we have the supported version be per branch. That way we can keep people from switching back to stable on a version that isn't supported in stable yet.

[matteodelabre]

Technically they would still be able to install by using --force on the reenable. Fair point though, we should check something to see if the supported version has changed. How do you want to keep track of that?

The solution I have in mind is to publish a file on our website containing compatibility information. For example, we could add a file named Compatibility in both /stable and /testing subfolders. The file contents could look something like this:

Max-OS-Version: 2.12.2.573
Max-Build-Timestamp: 20220303120824

The version field would be used for displaying information to the user on the latest supported version, and the timestamp field would be used for comparison with the /etc/version file.

I've seen some people running switch branch without understanding what it actually does already. We probably should include a version check there still, but only if we have the supported version be per branch. That way we can keep people from switching back to stable on a version that isn't supported in stable yet.

Sounds good. Should we also call the check function in the bootstrap script?

[Eeems]

The solution I have in mind is to publish a file on our website containing compatibility information. For example, we could add a file named Compatibility in both /stable and /testing subfolders. The file contents could look something like this:

Max-OS-Version: 2.12.2.573
Max-Build-Timestamp: 20220303120824

The version field would be used for displaying information to the user on the latest supported version, and the timestamp field would be used for comparison with the /etc/version file.

Seems reasonable. We will have to split this information between rM1 and rM2 somehow. Do you want me to update the PR to handle this?

Sounds good. Should we also call the check function in the bootstrap script?

I think it would be a good idea to do so.

[matteodelabre]

Added a quick implementation of what we discussed above. Untested for now.

[Eeems]

Added a quick implementation of what we discussed above. Untested for now.

Did you ever get a chance to test this?

[Eeems]

@matteodelabre poke

[matteodelabre]

#616 is a reminder that this needs to be finalized. I probably won’t have enough time for this until the start of next month.

[Eeems]

@matteodelabre poke

[Eeems]

#731 we probably should focus on this again soon.

[Eeems]

Unfortunatly using /etc/version as an always increasing value will no longer work, one of the 3.6 releases has a value from 2018. We can pull the official value from /usr/share/remarkable/update.conf similar to how codexctl does https://github.com/Jayy001/codexctl/blob/7aedd90a7686db014329591767f3ba5eb81cfb29/local/codexctl.py#L100C14-L105

[Eeems]

I've updated the logic to handle minimum and maximum versions, this should provide the building blocks required to start generating multiple repos with different OS version ranges. I haven't tested anything yet, but in theory it should work. I also fixed up the version compare logic to use opkg compare-versions as the current logic seemed to always fail when trying to run it.

[Eeems]

Closing in favour of #759