RC12 StrongHelp/PackMan bug

The Obey file $.!Boot.Resources.!Packages.SetVars sets the RunType for 3d6 (StrongHelp) incorrectly to point to $.Apps.Utilities.!StrongHelp. The Obey file helpfully states that it is automatically created by !RiscPkg and therefore any changes will not be preserved!

!StrongHelp is now in $.Apps in the disc image so I suspect that you don’t see the error until !PackMan does an update…

The solution would be to make sure that !Packman updates itself before trying to update anything else…

Funny. On my Pi it is set to point at $.Apps.Misc.!StrongHlp — which does exist in addition to $.Apps.!StrongHlp. This is with RC8.

The latest version of PackMan is moving away from the SetVars you see above and is instead using the RISC OS look at option to set variables. In this case if you moved an application it just doesn’t get found so the variables aren’t set, so would solve your problem from the other thread about using the variable to detect if it’s available.

I think the solution for now would be for the packages paths file to be updated with the new location of !StrongHlp in the RC12 image. Not sure who does that though.

I think RC12 may be fixed (that is in the ‘tablets of stone’ meaning not the ‘repaired’ meaning)…

Packman 0.8.1 upgrade does not work on the Pi – the 0.8 version prevails after the update. Even after manually replacing the 0.8 version with the 0.8.1 version, StrongHelp files still fail.

Chris,

It sounds like the problem is the package database is incorrect on the RC12 image. So PackMan is updating itself to the location it thinks it should be in. Until the database is corrected it won’t help with the StrongHelp files either.

The simplest way to fix this is to move the PackMan and StrongHelp applications using PackMan’s Components window. From there drag the application icon to it’s new location. After this is done PackMan will do future updates to the new location and the system variables should point to the new location.

Yes, there were a few RC12 SD cards that went out of the door with the wrong Choices settings in them. At the moment, if you find you’ve got a copy that’s like it (the clue is it has no repositories configured when you first start it), you’ll have to do the fix-ups that Alan has given.

The underlying cause of this is that building disc images is still a manual process. Some things are managed by PackMan and some aren’t. So a build is a mix of PackMan and manual copying files about. Sometimes it goes wrong :(

What we’d really like is a way to autobuild disc images from the latest OS sources and the latest packages available. There are a number of pieces to this puzzle – one is FileCore write support on Linux that I recently suggested as a bounty – this would mean the autobuilder could write its own disc images.

I can confirm that the bug is still present in RC12a (and I have updated the bug tracking #382 to say so). This is a serious bug – inability (for novices) to read Help files is a major problem as it means that inexperienced users should avoid !PackMan completely. It is one more thing that prevents RISC OS on the Raspberry Pi from being considered stable.

If you take a vanilla RC12a SD card image and then fetch a single application using PackMan (in this case !Cat) it fetches the application correctly but when you try to look at a stronghelp file provided with the app, the OS checks whether the !StrongHelp app is running (it is not, so Wimp Messages won’t work to open the file) then checks the filetype run OS variable (it is set, otherwise it would say nothing recognises this file type). The application is intelligent enough (because of bugs in Virtual Risc PC) to check whether the filetype run has been set (it has, otherwise it offers a simpler text help from the Applications ‘Help’ menu entry in the switcher) then the OS produces an error message (because the filetype run points to $.Apps.Utilities.!StrongHelp which does not exist).

In a plain vanilla RC12a SD card image (before using !PackMan) I can open stronghelp files with no problems. Use !PackMan, accepting the package directory it suggests, and the bug appears.

Surely !PackMan can update itself? !Store does.

This is a serious bug – inability (for novices) to read Help files is a major problem as it means that inexperienced users should avoid !PackMan completely.

Wait… Have I misunderstood you, or are you saying that it is a serious and major issue that people don’t read the documentation?
If this is so, you might want to pop over to web.ornl.gov to see if they have a bug tracker where you can report this sort of thing.

It is one more thing that prevents RISC OS on the Raspberry Pi from being considered stable.

I wasn’t aware that !PackMan was included. My Pi install has !Store.

Furthermore, it is probably not beneficial to complain to the maintainers of the operating system when a third party application screws things up.

Surely !PackMan can update itself? !Store does.

I recall a while back some politics regarding what PackMan would and would not maintain; citing a failed installation of something (Nettle?) because PackMan refused to touch a pre-existing resource (UnixLib?) and thus did not bring it up to date as required by what I was installing. I gather the feelings at the time were that it was better to leave existing things alone, and by consequence install products liable to fail, instead of – you know – asking.
This may or may not have been fixed since then. I downloaded my “packages” from riscos.info and installed them manually… Much less bother. ;-)

Surely !PackMan can update itself? !Store does.

Of course it can fetch its own updates – it just doesn’t do it automatically when run – it needs the user to initiate the fetch.

Wait… Have I misunderstood you, or are you saying that it is a serious and major issue that people don’t read the documentation?

Ho, ho! What I am saying is that it is a serious issue that a novice would be unable to read the help files. Whether they do or not is up to them…

Chris,

The “bug” is still with the database used by PackMan that is shipped with the image. The latest version of PackMan uses entries in the “Look At” Boot options to set these variables. This makes it less likely that this kind of problem will occur. It does need a packaged version of StrongHelp with the new Components field to be used (and I don’t think that is in the main repository yet).

The solution is still for ROOL to fix the database.

Rick,

Furthermore, it is probably not beneficial to complain to the maintainers of the operating system when a third party application screws things up.

In this case it is the maintainers of the image you downloaded (who are the maintainers of the operating system) that need to fix the problem. They have put an incorrect file on the image that causes the problem with the third party application.

With the limited man-power and time they have it’s not surprising things like this can slip through the net, so it’s good of Chris to try the latest releases and report any problems.

I recall a while back some politics regarding what PackMan would and would not maintain; citing a failed installation of something (Nettle?) because PackMan refused to touch a pre-existing resource (UnixLib?) and thus did not bring it up to date as required by what I was installing. I gather the feelings at the time were that it was better to leave existing things alone, and by consequence install products liable to fail, instead of – you know – asking. This may or may not have been fixed since then.

I think it has, you are probably thinking of a very old version of PackMan. For quite a while it has offered to backup and replace existing packages. The latest versions are smarter about installing modules and will use an existing one if it is new enough.

I downloaded my “packages” from riscos.info and installed them manually… Much less bother. ;-)

Which is a perfectly valid way to do it. I find PackMan much less bother;-) (but as I maintain it I suppose I would).

As always, constructive feedback on how to make PackMan easier to use is welcome (but please try the latest version in case it already offers improvements).

Chris,

The “bug” is still with the database used by PackMan that is shipped with the image. The latest version of PackMan uses entries in the “Look At” Boot options to set these variables. This makes it less likely that this kind of problem will occur. It does need a packaged version of StrongHelp with the new Components field to be used (and I don’t think that is in the main repository yet).

The solution is still for ROOL to fix the database.

Can you confirm whether this is still the case? The bug still seems to be there, whether or not I update the package list.

Can you confirm whether this is still the case? The bug still seems to be there, whether or not I update the package list.

Why are you aiming this at Alan? It’s not his problem to fix, it’s ROOL’s as he’s already pointed out.

What I guess happened is that StrongHelp was originally installed using PackMan to $.Apps.Utilities then someone felt that $.Apps was a better place for it and moved it there manually, ie not through PackMan. As a result PackMan still points to the old install location1.

To fix this, StrongHelp needs to be moved back to $.Apps.Utilities and un-installed using PackMan. Then install a new copy of StrongHelp and, if desired, move it using PackMan to $.Apps.

You can do this yourself to fix the problem locally, the RC12 image needs to be fixed by ROOL of course.

It does need a packaged version of StrongHelp with the new Components field to be used (and I don’t think that is in the main repository yet).

The StrongHelp (2.87-4) package has been updated to the latest format and no longer uses system variables. It’s available from the ROOL repository.

¹ This is something people need to be more aware of when using PackMan. When I got my RPi from CJE the RISC OS image had been copied to an SD-card with a different name from the original one. This caused errors during boot-up as PackMan still referred to the original disc name.

Many thanks I have passed your suggestions onto ROOL and updated the bug ticket #382.