Updating RISC OS

I would very much like a utility that would tell you what non-ROM modules and resources you have on your system, where they are located on disc, whether they are up to date and what new features have been added since the version found. Also from where to download the latest version.

The HardDisc zip file on the ROOL site is updated continually but it is not a trivial task to update your machine without overwriting something that you downloaded ages ago.

I agree 100%: upgrading (especially from an odd- to even-number ‘official’ release) is not trivial, in fact my SOP is to start with ‘virgin’ components and painstakingly rebuild my personal desktop by hand, testing compatibility at each stage, and periodically making a disk image to roll back to in case of problems. But I wonder if !Packman could be adapted to find and replace all critical OS components when upgrading, in the same way as it will search out and replace all related components when upgrading !Otter, for example? That seems to work pretty well.

Gets my vote. Updating or even trying to determine how outdated some OS components might be can be such a pain!

Me too! ;) After giving my Kinetic RISC PC a spring clean – trying to get RISC OS 4.39 running without a cursor corruption. I can fully understand why such a utility might be useful.

PS. During the process I even utilised the pre-RISC OS 5 !System resources (PlingSystem.zip) which caused !TechWriter to have a meltdown. To solve this I utilised RISC OS 4.39’s clean (upgrade) !Boot.

Related thread: https://www.riscosopen.org/forum/forums/2/topics/9396

I’ve recently been playing around with ways to build packman/riscpkg packages from makefiles, and the approach I’ve devised should be easy to adapt to the way components are handled in the RISC OS sources. However I suspect that some work is still needed to restructure the boot sequence/disc image to allow it to be effectively packaged.

Also from where to download the latest version.

Who manages and coordinates the list?

not a trivial task to update your machine

Excepting the FAT Loader “partition” file, would it not suffice to:

• Rename !Boot
• Unpack the new !Boot
• Move the Loader file back (never ever copy it)
• Copy back the contents of the original !Boot with the Newer option?

Admittedly, I don’t update boot much because… it’s a hassle… ;-)

some work is still needed to restructure the boot sequence/disc image to allow it to be effectively packaged.

No doubt. And of course there are plenty of other issues competing for attention. But this would be a significant step forward in making the OS more user-friendly IMHO.

would it not suffice to:

I’ve not done that, but I’ve used !Boot merge in the past, which I assume works in a similar way, and the problem comes when, after upgrading thus, an app stops working or the OS throws up an error message, or simply fails to launch the desktop: where do you start? How do you roll back to where you were? In the end I concluded that certainty is all, and it’s best to start with guaranteed pure components (ROM + latest HD4) and add personal stuff progressively back in, testing at each stage. But it takes the best part of a morning, and frankly I can’t see newcomers to the OS persevering with such a laborious process.

or simply fails to launch the desktop: where do you start? How do you roll back to where you were?

This might help – http://heyrick.co.uk/software/harinezumi/

This might help – http://heyrick.co.uk/software/harinezumi/

Thanks, looks as if it might well – I’ll give it a go next OS upgrade. But as Jeffrey says in the link he quotes above:

Upgrading !Boot is troublesome / users can break things / etc. Potential solutions include:
Restructuring the boot sequence to allow it to be managed via PackMan: https://www.riscosopen.org/forum/forums/5/topics/3178, https://www.riscosopen.org/forum/forums/2/topics/3704
Storing Boot in ROM: https://www.riscosopen.org/forum/forums/2/topics/2589
Splitting Boot into different components based around usage: https://www.riscosopen.org/forum/forums/2/topics/9176

and AFAICS that sums up the options for future improvement in this area.

I agree and disagree!

Updating the ROM and HardDisc4 is a pain in the bum,but then so it is for most RISC OS apps. For reasons which don’t make sense to me, there seems to be a general community refusal to embrace packaging.

Finding, downloading, installing and updating software is just painful. And I include my own in that! So all of this can and should be a improved.

However… Nightly builds of RISC OS are really for techies, aren’t they? If you don’t know what to do, then perhaps you should buy a stable, and presumably easy-to-update, system from RComp or CJE? Having written that, it does sound a tad arrogant…hmm…

Nightly builds of RISC OS are really for techies, aren’t they?

Yes, but that isn’t the point: /any/ upgrade of the OS currently requires an undue level of technical expertise, as well as time and patience.

Hmm, fair point. Going from 5.22 to 5.24 via the official images could be a bit chewy.

What are the CJE/RC machines like? I assumed, perhaps wrongly, that they would be easy to do.

What are the CJE/RC machines like?

I don’t know: I’ve been a Pi user since getting rid of the Iyonix so have always ‘rolled my own’. Maybe a forum reader with relevant experience could enlighten us?

What are the CJE/RC machines like?

I can answer for R-Comp: if you buy an ARMX6 you get an update utility that shows you what has changed and updates your machine for you.

Did it cope OK with the transition from 5.22 to 5.24?

Yes, but that isn’t the point: /any/ upgrade of the OS currently requires an undue level of technical expertise, as well as time and patience.

I find it quick & simple to update using DirSync. Even allows for checking files you’re not sure about by calling SideDiff. I don’t think I’m clueless but nor am I a ‘techie’.

I find it quick & simple to update using DirSync.

Good suggestion! I’ve got DS and use it regularly, but never thought of using it in the context of OS upgrading.
I’ll give it a go next time – thanks for the tip.

I just have to remember not to update things like SparkFS if you’re using the full, paid for version.

Maybe there should be a “patch pack” for updating stuff in !Boot? Most of the harddisc4 content won’t have changed from one time to another. Easier updates, less bandwidth…

I just have to remember not to update things like SparkFS if you’re using the full, paid for version.

Or put things like your full copy of SparkFS in a directory like “Utils2” and set the system to look at or run that copy at boot time.

Overkill. I’ve never actually made that mistake. The comment was just intended as a friendly reminder not to let DirSync run on ‘autopilot’.

Thinking about DirSync, I’m struggling to see how what it does is essentially different from the !Boot Merge process in Configure.

I just have to remember not to update things like SparkFS if you’re using the full, paid for version.

Hmm, that’ll be an interesting one for PackMan to deal with. I guess the “root” disc image package would have to depend on all the packages that are required to exist (like !Boot), and then all the optional packages (SparkFS and most other default apps) would be listed as suggestions rather than dependencies. That way the user should be able to uninstall or opt-out of installing the things they don’t want/need.

Maybe there should be a “patch pack” for updating stuff in !Boot? Most of the harddisc4 content won’t have changed from one time to another. Easier updates, less bandwidth…

Almost as if there were some kind of packaging system in place? ;-)

I used SparkFS as an example but, as another example, DirSync offers PlingBoot.!Run as a candidate for update because of changing file dates. Here that would kill harinezumi.

One of the main problems with doing a custom update of the harddisc4 contents is that the file datestamps get updated with each build even when the contents haven’t actually changed.