Easier access to VersionNum

Would it be possible for the download table to include another column, linking to the VersionNum file for that component in CVS? I can never find the thing, that’s all!

That would sound reasonable. As Jeffrey said, the ModuleDB file in castle/RiscOS/BuildSys contains a good list of components’ locations, but not quite the location in the source tree :( I’ve been working on a new version of our build process which keeps the source tree as it is in cvs, which means a new ModuleDB with full paths to each component. This is a damn sight more useful for everyone!

There are still some wrinkles to iron out there, but if anyone wants my new ModuleDB (it’s a handy reference) feel free to email me at srevill at risc os open dot org.

Another column seems unnecessary – the version number could simply itself be a link to the relevant file in CVSWeb.

Steve – presently the YAML configuration data contains insufficient information to implement this. We’d need to add another field. We could roll up the MD5 changes at the same time, but given all the talk about packaging etc., is this actually worthwhile, or is it likely to be superseded almost as soon as it has been implemented? Or is there these days an altogether better way? E.g. does ModuleDB already have enough information so we could use it somehow instead of the config.yml files and get rid of some of the information duplication therein?

ModuleDB is nowhere near what we need for the YAML stuff. I don’t think it’s a bad idea to have the MD5 stuff working – the backend is already implemented. Having the version number link to a VersionNum file (if one even makes any sense for that particular download) is more of a wish-list item. It could always be implemented as a “VersionLink” tag and we can populate the YAML gradually…

The point is, all this packaging stuff will take a while to get fully off the ground.

If MD5 is what I think it is, please don’t abandon it – there’s a field in the RiscPkg index file especially for it!

The existing interface will by no means be obsolete once packaging is rolled out – not everyone can be expected to install RiscPkg in order to download stuff. In fact, basically what packaging involves is a rewrite of the current code which bundles up the zip archives with a copy of the licence etc. to produce zips to RiscPkg specifications instead. Then it needs to write the relevant information about all archives to a publically accessible index text file (including size, MD5Sum, and URL to download zip from). That’s really about it. What I’m working on at the moment should give you a good idea how to go about it.

I see there is already a mechanism in place to specify the location on the user’s hard disc for the component to be installed – perhaps that could be adapted for the RiscPkg hierarchy?

This is how the ‘Disc’ build specifies where each component gets installed – note the INSTDIR parameter. The results of the ‘Disc’ build are what you see inside our HardDisc4 archive. These locations are from the fairly standard ‘Universal’ boot sequence layout.

Hmm. Well, that’s certainly interesting – and, unfortunately, completely incompatible with RiscPkg, which states that all applications must be kept in a directory called ‘Apps’ and then in a subdirectory named after the application’s ‘section’ (Games, Graphics, Audio, etc.) – and that’s also where the application forcibly installs them on the user’s hard disc. Oh, dear – Alan, please help us! That’s two inadequacies so far – the lack of the dummy !Boot thing, and inability to specify a hard disc location for installation. Surely it could only take an extra field in the ‘Control’ file? I really don’t want to start messing with the structure of the hard disc image…