Unfortunately, the vendor solution for package management is a mess, as there are N different formats, and each distro has their own set of standards. This has traditionally just been offlifted to contributors, but if you look at how commercial vendors distribute large Linux solutions, they either pick a package management solution (.rpm) and expect the community to cope.
Additionally, no popular package management solution allows installing user-specific packages, which would mean that either the user would have to enter their root password every time a game wants to be installed / updated, or Valve would have to do something silly like a setuid daemon.
Package management is in an unfortunate state for commercial vendors, and some people are working on a few solutions to these problems, but pragmatically, it's not in a good place for Valve to depend upon right now.
Delivering a simple postinst / preinst file through facade packages is a bad idea for many reasons (I could enumerate if you would like me to), and I doubt distros would accept the packages upstream. It seems like it's just a lot of effort for no real benefit.
Steam actually is installing software on the computer, so what's the reason why it shouldn't deliver a root daemon undertaking the task to install such "dependency" packages for the users? Thats definitly better than steam doing this apart from the package management.
The problem that distros would never accept such "dependency" packages it a completely different, they won't accept the steam package either. Steam is breaking the whole concept of "just root installs software on the computer" - but it has to. Steam doesn't target "classic" multi-user-systems, it targets single-user-systems and multi-user-systems where everybody should be able to do such things. The last problem you mentioned are the different package management systems. This actually has nothing to do with my suggestion and already is problematic with just the steam package.
Maybe I misunderstood your suggestion, then. From what I understood, you wanted Valve to ship packages for every game that simply contain preinst/postinst that tell the Steam client to download data. That requires them to understand the myriad of different package systems -- not every package system does preinst/postinst scripts in the same way, and they'd have to create a system to generate these facade packages and test it.
Then what? When a new update gets pushed, do they just bump the version and hope that the upgrade script gets run, and that tells the Steam client to update the game?
Where would the game get installed to? The system directories? From what user account would Steam download the data? Would you have a system configuration file that lets the daemon know your user credentials, so when you install a new game, it downloads? What's the failure system for that when something is misconfigured? Do you abort the entire system update, or not? Most package management systems are not transactional, so when a system update is aborted, the system is pretty much hosed.
How do you deal with multi-user systems?
So, what exactly does integrating with the system package manager give you? It seems there's a large number of downsides to integrating with system package managers, it's a lot of work, and I can't think of a single upside to it.
Most of game packaging problems may be solved with PackageKit
PackageKit is a wrapper around package managers. It does not solve any of the problems listed above.
At least it solves permission problems, allowing steam to install packages without password using policykit settings.
It allows the Steam client to install the game without a password prompt, assuming PolicyKit is properly configured (in the default configuration, this will only happen for signed packages for which the user has the GPG key).
The existing Steam client can do this right now, without any of the drawbacks listed above.
I think your request can't be done. Steam is platform itself, you want to break it. It should be multiplatform in all aspect. It can't be done with system package simply because you need root permission, each distro is different, etc... More troubles for nothing.
Nothing extracted yet.
Please use the package management system more heavily and don't try to reinvent the wheel. The greatest example are packages for games: When you provide such packages, you could let the package management system handle with dependencies, special files like the
.desktopfiles and you won't break the whole system when removing steam (all packages you install manually won't be removed, because they don't depend on the steam package).I do not suggest to release the sourcecode of games, I even do not suggest to deliver any game files using the package management system. I suggest to use the dependency management. You could easily use the maintainer scripts - e.g.
postinstexecutes steam what downloads the actual game files (likesteam://install/<ID>) andprermremoves all files installed by steam (likesteam://uninstall/<ID>). You could check within thepreinstscript that a user really owns that game, but even when you don't do that, just nothing would happen - the game files won't be downloaded anyway.