Thanks for putting this up, Peter. We haven't gotten our own repository up yet so having this service is very useful.
The .info file does indeed spec database support as you're assuming in your XML snippet.
The OpenACS core and APM support legacy ACS 4 Classic packages as well as those extended to work with our core. I just moved a large ACS 4 Classic site to OpenACS 4 as an experiment with no problem. There are some minor differences in acs-messaging and acs-mail, but I think those could be replaced with their ACS 4 Classic versions if someone didn't want to do the minor hacking necessary to use our slightly modified stuff.
OpenACS 4 incorporates a bunch of bug fixes and some (though not many) important performance enhancements, especially in the area of permissions checking.
So ... in an ideal world you folks at Ybos might explore loading up your custom packages written for ACS 4 Classic on OpenACS 4. You might find it painless. Or perhaps very slightly painful. I doubt it would take someone more than a day or so (given a machine that runs Oracle reasonably fast!).
It would be an interesting experiment.
The reason I mention this is that OpenACS 4 packages running on the ACS 4 core will break (the APM will choke). So maintaining a repository with application packages from both code bases would confuse someone using ACS 4.
On the other hand, someone running the OpenACS 4 core should be able to download a package and our APM will recognize it as being Oracle-only if it's an ACS 4 Classic package, and Oracle/PG if it is one of our fully-ported OpenACS 4 packages.
I'm rambling but hopefully this makes some sense?
