Hi Richard,
My company has need of proper package feeds that support multiple active OS releases. That is, we need to have the ability to work on OSv1.1 and OSv2 simultaneously. The problem we are having is that PRAUTO responses from the prserver do not have a concept of OS release. The later query gets a higher number. So if we build OSv1.1 after OSv2, that means that OSv1.1 has a package with a greater PRAUTO value than it's counterpart in OSv2. In that scenario, our OS dist-upgrade will be incomplete. I solved this initially by hacking the PRserver to include an int os_version, based on a variable in our site.conf. And then I changed the prserver to support this extra param with another column in the database. Now queries to the prserver consist of a tuple like ("base-files-1.0-r0", "aarch64", "12345678978", "11") where "11" is the new os_version param, and the OSv2 counterpart ("base-files-1.0-r0", "aarch64", "12345678978", "20") where "20" is the new param. The SELECT queries to the database find the max value for that package/arch and os_version <=X.
In this manner, any increase in the OSv1.1 package, will cause the OSv2 package to get bumped on the next build automatically, regardless of a checksum match or not.
Recently with our Honister upgrade, we had the added complexity of changes to the transport protocol (xmlrpc to socket+json) as well as simple changes to package.bbclass has caused us redo some things. And hence the idea of being able to provide our own custom prserver client for bitbake to consume.
I hope this explains our needs well enough.
Rusty