I have IPFire 2.27 (x86_64) - Core Update 167 Development Build: master/24c8e6a6 installed and now that stable Core Update 167 is released, I wish to return to stable builds. Pakfire doesn’t offer to install the stable version (Stable is selected in Settings, Repository).
I will be reluctant to test future development versions if I can’t move back to the stable version after testing is concluded.
I’d like to see an option to do this from the web interface. Something as simple as adding an input box that displays and changes the contents of this file. The display of this input box could be limited to only show when Testing or Unstable is selected in the dropdown.
reverting from testing to stable of the same core level does work, as described above
OTOH, reverting to stable, from an as yet unreleased testing core is problematic, because many settings and modules have been upgraded. Consequently, it should not be attempted.
The reversion issue was discussed in an earlier thread some years ago. Guidelines put forward then included:
advisable to maintain a separate device, running stable (as ARM users found, multiple test releases of core 167 produced an unworkable upgrade)
testing releases are oriented to more experienced users, who are likely to be able to document results, as well as being able to use command line to revert, if appropriate
I’m not so much interested in “reverting” which I take to mean 166 stable → 167 dev → 166 stable. I’m interested in 166 stable → 167 dev → 167 stable.
For example, I (and others) reported a bug having to do with DNS updates from DHCP leases. This was reported as fixed in 167 dev version so since I reported the bug, I wanted to test the fix (and report back if it didn’t work). The fix worked, 167 stable was released, and I wanted to return to the stable release(s).
Changing the contents of /opt/pakfire/db/core/mine worked but I believe there should be a way to do that in the GUI.
An issue with doing that in GUI, is that less experienced users could change & save GUI settings, without adequate understanding of potential consequences. It would require a decision tree, built into the GUI procedure, to prevent the reversion to prior release, during testing phase.
Testing release of next core is often available only a few days following stable release of the current core, resulting in limited need for what you are seeking. I have two hardwares permanently on testing and a third on stable. I’ve also been given an Nanopi R1S H3, which I could now use to test the revised upgrade procedure from 166 to 167 stable, on arm6hl.
The above posts should convince you not to use your “main” (production) IPFire device for testing. And it should have convinced you to build up a “spare” (old) computer and assist in testing (on the spare).