RISC OS packages

This is a follow up to Sprow’s post about RC16 containing packaged apps:

Fortunately all the apps supplied with RISC OS are individually packaged, synced from a central repository, with an update source which is in the list for PackMan in the latest RC16 Pi release.

This is great news, pass on thanks to those involved in this. I’ve taken a quick look and have spotted some potential issues:

Apps
!Director – not from a package?
!NetSurf – not from a package?
!Store – not from a pacakage?
!StrongEd – not from a package?
!StrongHlp – is packaged, but the install hasn’t come from the package

Diversions
!CoundDn – is this from a package?
!Doku – is this from a package?
!Poker – is this from a package?
!SChain – is this from a package?
!SignalBox – is this from a package?

Documents – all except UserGuide don’t appear to have come from a package

Printing
!PrintPDF – not from a package?
Pdf – not from a package?

Programming – is any of this from a package?

Sources – is any of this from a package?

Utils
!7backup
!DPingScan – threw conflicts when updated
!ePic – not from a package?
!InterGif – not from a package?
!Manuals – not from a package?
!Patch – not from a package?
!Periodic – not from a package?
!PrivatEye – not from a package?
!SparkFS – not from a package?
!SwiftJPEG – not from a package?
!UnTarBZ2 – not from a package?
!WinMenu – not from a package?

PipeDream installs its manuals to $.Manuals.PipeDream and its examples to $.Documents.PipeDream? Why does PipeDream need it’s own Manuals folder?

The other apps all look good and the few that have since been updated did update correctly.

Taming the monster that is the Boot application remains to be packaged, if anyone’s at a loose end?

This is going to take some work. In particular any apps installed under !Boot, such as in Resources must be checked to ensure they do not write settings to their install folder.

A useful one to package would be Loader so we can update RISC OS to the latest Beta. I’m not sure if PackMan will complain about CONFIG/TXT and other extra files being in the folder – it might need some tweaks.

!CoundDn – is this from a package?

Yes, as is !Cat, although that is not on RC16.

!PrivatEye – not from a package?

I’m figuring out how to package PrivateEye at the moment (it depends on Tinct so I’ll probably have to package that too).

!PrintPDF – not from a package?

It has been packaged, along with some of my other software, for a couple of weeks. That’s probably not enough time to have been of any use to anyone in this context. :)

Taming the monster that is the Boot application remains to be packaged, if anyone’s at a loose end?

I’m still of the opinion that !Boot should be restructured so that the read-only bits are separate from the writeable bits. E.g. the Choices folder (or perhaps an external !Choices app) should start off empty, and should be the only place within !Boot where user settings are saved. The rest of !Boot should be “read-only” packaged components which are only written to when upgrading those packages.

Also since Rick mentioned RISC OS 3.10 in the original thread, it’d be nice to have the packages break down in a way where people can easily create a stripped down version of the boot sequence for use on Archimedes machines (e.g. small enough to fit on a floppy, doesn’t load a bunch of sprites, and ideally doesn’t load any modules by default). But I recognise that may not be a suitable thing for ROOL to focus on (and it’d probably be easier to have the Archimedes boot sequence be a completely separate project, rather than making it a stripped down version of the 3.5+ boot)

Network booting is another thing which would be nice to support.

See also this thread (amongst many others) for some previous discussion about !Boot issues/improvements.

@ Jeffrey Lee

Is it possible to add an “official” container for 3rd parties commands and utils? For example !System.[OS_VER].bin as for /usr/bin on Linux? I know we could use !Boot.Library or !Boot.Utils, but I think they are better suited for ROOL stuff.

I like the !Choices idea, but does it still needs to contain Boot.PreDesk/Tasks etc.? wouldn’t it be better to separate the ROOL specific pieces from the User’s or 3rd parties? (I mean in the past these have been source of troubles)

!DPingScan – threw conflicts when updated

The wonders of package management. How can a stand-alone application with no external dependencies or requirements conflict with itself? Perhaps someone who understands all this could explain in words of few syllables.

PipeDream installs its manuals to $.Manuals.PipeDream… Why does PipeDream need it’s own Manuals folder?

PipeDream-Manuals just specifies to be installed using the Manuals path in PackMan (See Advanced > Paths). But it would seem that few others do? Fireworkz-Manuals and RiscPkg-Policy are the only other two packages I have installed that also use the Manuals path.

Is it possible to add an “official” container for 3rd parties commands and utils? For example !System.[OS_VER].bin as for /usr/bin on Linux? I know we could use !Boot.Library or !Boot.Utils, but I think they are better suited for ROOL stuff.

I’d always considered !Boot.Library to be an official place for user & 3rd party utilities. So this raises an interesting question: Did Acorn actually produce a specification for the universal boot sequence? I’m struggling to find a good reference for how Acorn expect people to use the thing.

I like the !Choices idea, but does it still needs to contain Boot.PreDesk/Tasks etc.?

The PRMs say that apps can write to Boot$ToBeLoaded (i.e. Choices.Boot.PreDesk), and Boot$ToBeTasks (i.e. Choices.Boot.Tasks). So those folders will still need to exist for use by third-party apps. But possibly we could have a separate location for users to put their own custom scripts, and another location for the ROOL boot sequence.

@ Jeffrey Lee

Did Acorn actually produce a specification for the universal boot sequence?

Indeed a good question!

What I know (and I may remember this wrong) is that UniBoot release 1.0??? was introduced in 1994(?) and called (temporarily?) !ArmBoot and described as !Boot, all the details of the first release are on Support Group Application Note 251 and RISC OS 3.50/3.60 User Guide (part Modifying the system start-up configuration).

I am just out of a very very busy day at work and too tired to read all the details, but I hope the refs above are useful.

A useful one to package would be Loader so we can update RISC OS to the latest Beta. I’m not sure if PackMan will complain about CONFIG/TXT and other extra files being in the folder – it might need some tweaks.

There’s some code for this in the raspberrypi-rom and raspberrypi-firmware packages in the GCCSDK autobuilder. However at the time the ROOL build system was packaging unaware so I was having to scrape the downloads from the ROOL website. And the process of deciding which firmware to use was manual. It did work (I demoed it at a London show, maybe 2012/13?), but it needed manual maintenance and the risk of unbootable systems was non trivial.

It’s good to see software maintainers in the posts above are helping with the packaging effort.

And the process of deciding which firmware to use was manual. It did work (I demoed it at a London show, maybe 2012/13?), but it needed manual maintenance and the risk of unbootable systems was non trivial.

The Pi foundation appear to have this problem solved, could we not have two packages that sync the firmware files from their current Linux firmware package along with the latest nightly and last stable release so people can choose which update channel they want to use?

There have been times when the latest Pi foundation firmware bricked RISC OS, because they changed something and RO hadn’t yet caught up to match. The indicator of ROM build x works with firmware build y is not something that was codified – it was people on the forum trying things and posting what worked for them, but not in a way the build scripts could use. If you want to run an automated build process really you need some kind of automated testing to confirm that x and y achieve a successful boot before you think about shipping ROMs.

You’re possibly over complicating the requirement. If you’re concerned about people just accepting updates and bricking their machines, just add more update channels:

Pi RISCOS Stable:

• RC16 ROM

Pi RISCOS Nightly:

• Nightly ROM build

Pi Firmware (ROOL Stable):

• RC16 Firmware

Pi Firmware (Pi Foundation Stable):

• Firmware from libraspberrypi0 libraspberrypi-bin raspberrypi-bootloader raspberrypi-kernel

Pi Firmware (Pi Foundation Current):

• Firmware from https://github.com/raspberrypi/firmware

Source for Pi Firmware details.

You could do it like that, but I think what people want is to upgrade to the latest ROM and get the firmware that matches. Bumping the firmware version is something that should happen as part of a commit to the RO source tree after some degree of testing, rather than just getting the latest and hoping for the best, Even if the firmware is stable for Linux it doesn’t mean it’s stable for RISC OS. And while the Pi firmware has settled down since the early days, I could still imagine breaking changes on the Pi 4 and other new board releases.

That said if there are security issues in the firmware. that might tilt towards ‘get the latest and take the fallout’…

I think what people want is to upgrade to the latest ROM and get the firmware that matches

Which is what the stable channels serve as they’d be coming from ROOL tested sources and only updated as RC’s are released.

just getting the latest and hoping for the best, Even if the firmware is stable for Linux it doesn’t mean it’s stable for RISC OS

There are a small set of users that actively test the latest firmware with RISCOS and report upcoming issues, me included. Updating the ROM and firmware is currently a real pain due to the manual nature of it, an official package source would be very useful.

The biggest issue I perceive for PackMan sourced OS ROM updates is the issue of Module renumbering, which has caught me out far more times than breaking due to updating to the latest Pi firmware.

The other apps all look good and the few that have since been updated did update correctly.

I have tested my software on RC16 and it updates correctly:

!CoundDn – is this from a package?

Updates correctly to version 0.24 (1-Jan-2020)

!SignalBox – is this from a package?

No.

Other software of mine that is packaged (but not included in RC16) is shown correctly under PackMan on RC16:

!Cat version 0.24 (dependency: MakeDraw)
!MakeDraw version 2.70
!SudoTutor version 0.01

Could I please make a small suggestion for Packman? I think it would be useful to be able to filter by source, so that I can see just packages from one repository at a time to make it easier to find what I’m looking for. When you just have a list of package names it isn’t easy to tell the source it is coming from – not sure if there is a way of telling.

It shows the source URL in the ‘info’ display.

Could I please make a small suggestion for Packman? I think it would be useful to be able to filter by source, so that I can see just packages from one repository at a time to make it easier to find what I’m looking for

+1 to that, I’m constantly turning sources off and updating the list, to cut the list down to the source I want to use.