Packman/PlingStore Obscurity

While you’re all considering how to maintain packages, perhaps you’d like to consider my dilemma, which I’ve emailed Alan about several times in the past few years.

Jon, I don’t seem to be able to find any emails from you. If I had I would have replied fairly quickly as I’d love to see your games packaged.

The package files are just zip files with a control and copyright file in a RiscPkg directory. These files are both text and can be create in a normal text editor or by nearly every programming language out there:-)

I’ve created package files on RISC OS and Linux. For RISC OS I either user my PackIt program or create the directory structure for the package with the control files in a temporary directory then use a command line zip program to produce the package. My TBX library did all this using a GCC make file on RISC OS. I also used a LUA script to update the version numbers everywhere from a single command.

You should be able to write a program, possibly even using your BASIC database to create the control files from your metadata.

If you are going to host them yourself the final step would be to create the package index file, which again is a straight forward text file with a copy of each control file with an md5sum added.

Please try emailing me if you need any assistance. I’ll make sure I reply within a day to two of the first email you send me so you know that the lines of communication are open.

If a tag is not included it must be assumed that the capability it represents is not supported.

There lies the problem. Every developer does not have access to every machine, so in this respect crowd sourced compatibility would be useful as others can feed back what does and doesn’t work.

I think all developers would love to have that feedback on where their programs do and don’t work. I think that the best that can happen for now is for the developer (or package maintainer) to make there best (informed) guess of the tags to include and hope for feedback if they get it wrong.

The important thing will be we can at least get a better, more targeted list of packages in PackMan and reduce the wasted time from installing stuff that won’t work anyway.

At first most of the tags will be unset, but hopefully in time more and more packages will be updated so the list will improve.

I’m still working my way through the code changes. But when I have something to release my next priority will be to add tags to the autobuilder packages, which will at least remove a lot of non-working things from the list on a RPi 3 until they can be updated.

I don’t seem to be able to find any emails from you. If I had I would have replied fairly quickly as I’d love to see your games packaged.

I’ve just resent the last eMail I sent, if you haven’t received it I guess I have the wrong eMail address for you.

The package files are just zip files with a control and copyright file in a RiscPkg directory

Is there documentation for the structure of these files?

If you are going to host them yourself the final step would be to create the package index file, which again is a straight forward text file with a copy of each control file with an md5sum added.

The intention is to host them myself, I’ll probably need some assistance on how to do that. Again, is there any documentation on the package index file?

The package files are just zip files with a control and copyright file in a RiscPkg directory

Is there some documentation for structure of these files?

http://www.riscpkg.org/policy.html

(P.S. Alan – it might be nice if that document used hyperlinks to associate terms/elements with their definitions)

bq. If a tag is not included it must be assumed…

No, it’s a tristate: Does work; Doesn’t work; Don’t know.

I don’t think we are necessarily disagreeing here.

If I may characterise your point it is that sometimes a positive assertion about the nonexistence of a thing may be necessary. For instance you might want to positively affirm that the SWP statement is present or that it definitely not present.

This can handled by having an agreed on negating form. For instance the prefix “no-”. e.g. “swp” and “no-swp”.

What I was attempting to suggest is that a tag may fail to appear for two reasons. Either that the concept it relates to is absent or that it is present but the tag is missing.

In light of this a client should probably assume that absence is intentional (it indicates absence) but acknowledge that it may be an oversight. It could do this by providing the option to view packages without suitable tags along with a warning that they probably wont work.

It’s taken me over a year and a half to get it done, but I’ve finally released a version of PackMan that supports an “Environment” field as discussed earlier in this topic.

Of course, at the moment only very few packages support it, so you will see a lot of warning triangles. I’m hoping to reduce that number over the coming months by:

• Fixing my own packages
• Rebuilding and uploading packages from the GCCSDK autobuilder. The autobuilder has been updated to support the new Environment fields.
• Giving ROOL a patch to add the Environment field to the HardDisc packages.

If you are the producer of packages please consider adding the Environment fields: I’ve added a page that may help at:
https://sites.google.com/site/alansriscosstuff/packaging/environment

If you can get stuff in the GCCSDK autobuilder building that is no longer building, that will help as well. I’d rather upload newer versions of the
underlying programs/applications that have been built with Raspberry Pi 3
support rather than just restricting them to machines before that.

(P.S. Alan – it might be nice if that document used hyperlinks to associate terms/elements with their definitions)

I’ve improved it a bit, but haven’t managed to update the RiscPkg site version yet. You can download the latest version via PackMan or I’ve put a copy at:

http://www.riscos.info/~abuckley/policy.html