Olf0
commented
1 year ago Definitely an interesting idea. Though I wonder if that is worth the effort, because …
- Jolla 1s (most of which start at SailfishOS 1.0.0 after a factory reset, the earliest ones at 0.99.x, the last ones sold at 2.0.0) are not supported any longer, so I assume most have been upgraded to their final release 3.4.0 already or are not in use any more. Furthermore they are very slow for recent standards, still their form factor has some appeal.
- only 1000 - 1500 Jolla Tablets were sold (which factory reset to some 1.1.x release, IIRC x ~ 8), they have had high failure rates at both ends of the "bathtub curve" (and most of them reached the far end already due to overheating when in serious use), their batteries tend to be worn out (i.e., "baked" due to overheating), they are not really supported since at least SailfishOS 3 (i.e., increasingly device specific software bugs appear, which are rarely fixed; it seems that Jolla does not really test SailfishOS releases on a Jolla Tablet for long and does not want to put resources into testing with them, understandably), they always were slow and run hot.
- less than 3000 Jolla Cs were sold, while having double as many CPU cores (4) than a Jolla 1 (2), each core is a lot slower (ARM Cortex-A7 vs. Qualcomm Krait 200). These do factory reset to SailfishOS 2.0.0 IIRC. Although some 10.000 Intex Aquafish phones have been sold, only a few people (I assume < 1000) have dared to reflash them to become a Jolla C (same hardware, except for the bands the 4G modem supports) via Coderus' guide at TJC, and Intex did not extend the support contract with Jolla beyond SailfishOS 3.0.0 (a release which causes some hiccups on them, so better stay at SFOS 2.2.1 or reflash to become a Jolla C).
Furthermore, I have never analysed where version --dup downloads the packages to and I have no idea how to trick it into using a local source for packages it installs.
And such a feature may collide with one or both points (each in one message) of issue #82 (which is on my ToDo-list for the upcoming months): This would have to be properly analysed and maybe a workaround can be found for this idea to work, when these are implemented.
Also I always avoided to install any packages for sfos-upgrade as dependencies, so using zypper is out of scope.
Still I will do my best to keep these old devices and this specific use case (upgrading to a recent SFOS release after a factory reset) well supported, so thank you very much for verifying that this still works with a Jolla 1 and a Jolla Tablet.
All in all I do not want to implement this, but contributions are welcome as usual, as long they heed aforementioned constraints.
DESCRIPTION
Having gone through a bumpy upgrade process from a SFOS 1.x release to current on a Jolla Tablet, the idea arose that, as the upgrade process basically does
... and repeats that process every time a particular update step is performed, why not skip step 1. by having the option to supply a prepopulated cache directory.
ADDITIONAL INFORMATION
Consider the case of a J1 or Tablet which has been reset to factory.
One would now go through the step releases to update to a certain target release. It's likely one has performed such an update previously, and it's likely the packages needed to do the upgrade have not changed since the last time.
So in case a (large enough) SD card is available, that could be used to persist the cache dir for every (stop) release, and supply it for repeated from-factory-reset upgrade tasks.