Olf0/sfos-upgrade

Add flag to skip stop releases

r0kk3rz opened this issue · 2 comments

r0kk3rz commented

For ported devices stop releases aren't always necessary or possible depending on the state of the adaptation repositories for that device.

it would be nice to tell sfos-update to skip the stop release and go straight to the version its been told to, with appropriate warnings of course

Olf0 commented

it would be nice to tell sfos-update to skip the stop release and go straight to the version its been told to, with appropriate warnings of course

I originally had such a "stop release override" present in line 225 ff., when ssu was manually set to the SFOS release to upgrade to before starting sfos-upgrade.
I omitted it long ago, because ABI / API changes (Kernel, GCC etc.) and complex dependencies (those unresolvable by libzypp, which is what zypper and pkcon use, probably Jolla's rnd-dist-upgrade too) do require not to "jump over" a "stop release" in the upgrade path to the intended SFOS release.

For ported devices stop releases aren't always necessary or possible depending on the state of the adaptation repositories for that device.

  • Mmmh, I still cannot see how "community adaptions" of SFOS technically differ in this regard from the device adaptions Jolla maintains.
    I.e., why omitting a "stop release" will definitely not cause issues on an installation of a "community adaption", while it might on a "officially" supported device.

    As I created sfos-upgrade to provide an automated and reliable way to upgrade at the command line, I am inclined to say "No" to changes, which may enable the user to cause havoc easily. People will likely blame sfos-upgrade for mishaps, instead of themselves. And that even would be understandable, as preventing mishaps (compared to executing these commands manually) is a primary goal of sfos-upgrade.

  • Introducing an additional flag would require a more sophisticated options parsing, either per getopts (which is a BASHism, which I try to avoid) or some other means. I considered this for long, but it will definitely break sfos-upgrade's API (CLI syntax), hence that would result in sfos-upgrade2. I still consider doing this (for a variety of reasons), ... someday.


If I am convinced that such a "stop release override" flag will not increase the probability of mishaps, when reworking the calling interface to create `sfos-upgrade2`, I will implement it.
Olf0 commented

@r0kk3rz, while at it (sfos-upgrade) again (PR #44) after a longer pause, I decided to take a look at this again:
After some consideration I reintroduced the ability to override the "omitting stop release prevention" for upgrades in "SSU mode".

To use it (i.e., to be asked, if one really wants to "jump over" a stop release), one has to set SSU to the version to upgrade to before executing sfos-upgrade without parameters:

ssu re <version>
sfos-upgrade

Hopefully this workaround satisfies the need for performing SailfishOS upgrades "across" stop releases you / your users expressed.

Side note: By avoiding to introduce real options (i.e., multi-argument parsing), this solution allows me to defer implementing a proper argument parser for long or indefinitely.

P.S.: This is released as sfos-upgrade 3.7.1.