On-the-wire dependencies

[Josef Spillner]

I wonder what could be done regarding the issue of different release cycles of 
game (server) projects and Debian, including its derivates.

If a game project releases versions X, Y and Z, and is only to host Z on its 
server, what will distros A and B do if they included X and Y and promise 
many years of support for it.

Obviously, depending on specific server versions is a bad idea, but this seems 
to be increasingly common. For example, there are many packages which have 
something to do with Google, and if Google changes its remote APIs then the 
packages will break. They already ceased to offer their SOAP service, and as 
a result, packages such as libnet-google-perl are basically worthless, unless 
someone writes a replacement service for it.
(Hm, I should file a bug report against it...)

I wonder what can be done about this for games which depend on specific game 
servers. For example, would there be an issue to let new game clients go into 
proposed-updates for a stable Debian release if that happens?

The package dependency management of dpkg is currently entirely unaware of 
such dependencies, but I think at some point one wants to keep track of this.
Suggestions?

Josef