[gccsdk] 'Stable' package repository

Theo Markettos theo at markettos.org.uk
Fri Jul 13 05:34:16 PDT 2012

I've been testing some riscos.info RiscPkg packages on the Raspberry Pi.  It
turns out that some don't work, largely it appears due to alignment
exceptions.  These can probably be fixed at the RPi end, but it did raise a
question about shipping packaged software.  It would be good if we can ship
PackMan on the RPi default image, so that new software can be advertised to
existing RPi users.

At the moment, riscos.info has a single repository index, 'autobuilt', in

There's also a 'test' image, but that seems to be older than the 'autobuilt'
version.  Maybe this already does what I want, I'm unsure.

It would be handy to be able to do wider user-testing on packages before
they're shipped out to the general user community (who most likely have much
less RISC OS experience than most RISC OS users today).  At the moment the
package builder does testing and then Alan turns the handle to ship it out
to 'autobuilder'.  That means there's no way to do wider user-testing on
that stream before it's published to all users.

Graham's riscpkg.org setup has 'stable' and 'experimental' indices, just
like Debian (But much of Graham's repository isn't ARMv7 safe, or is plain
confusing - eg these days Nettle is the thing to use for SSH, not

How about a 'stable' index on riscos.info, which requires a manual OK to
release a version (unlike, I think, 'autobuilt' which is generated by
autobuilder scripts)?  A 'manual OK' could simply be a list of approved
packages and version numbers, with the index generated automatically, but
more simply an edit of the existing package file.

Is the rationale behind 'autobuilt' that there would be a future index of
non-autobuilt things?

The other thing we'd have to be careful about is bumping package revision
numbers (ie the -1 suffix in fooapp_2.23-1.zip) so that old archives aren't
overwritten by new ones in the pool

I'm hoping that someone in the RPi user community might be willing to
maintain such a list, given there's lots of enthusiasm for testing at the
moment.  But at the moment the wish is to have a repository whose URL we can
ship and then allows testing and pushing out more packages after the release
deadline.  If nobody is available to maintain the list, the worst that can
happen is that such a URL is a mirror of the 'autobuilt' packages list, but
it would be useful to divorce the two to give the option later.



More information about the gcc mailing list