On Mon, Aug 27, 2007 at 09:53:07PM -0400, Michael Gilbert wrote: > Dear mentors and games team, Heh, more than 9 months old. But I only just came across the ITP. ^_^ > I am looking for a sponsor for my package "steam-powered". > * Package name : steam-powered > Version : 5 > Upstream Author : Michael Gilbert > * URL : no website > * License : gpl > Section : contrib/games I just had a look at your package (version 7) and a few thoughts came to mind. On a multi-user machine, this current setup (sticking stuff in .config/steam-powered) will lead to duplication of some very large files. (GCF files, and the contents of .ncf files) Would it not be better (and I don't know if this is rationally possible) to have a shared installation of Steam? As an outline/suggestion, it'd have to create a new user, which owns /var/lib/games/steam-powered/ say, and has a local wine-prefix in /var/lib/games/steam-powered/.wine and then installs Steam to /var/lib/games/steam-powered/Steam. I don't know however how good Steam is at locking files it's updating, but if it can handle that OK, then that mean that whichever user happens to run Steam and do the updates, all users on the system benefit from it. Steam already has a system for storing login-specific (Steam-login, that is) data, but short of building an appropriate symlink farm, that data will also live in /var/lib/games/steam-powered. (A symlink farm back to user's home directories won't work, because a Steam login might be shared by multiple Debian user accounts...) This also avoids the issue with the current code of playing with the user's .wine/dosdevices folder, and in fact the assumption that .wine exists. It would however require that all potential Steam users are able to gksudo or similar to the relevant user, gaining the appropriate wineprefix on the way. I haven't looked at how feasible that would be. I also haven't tried starting a wine session from a different wine prefix to one that is already running. I don't know if wineservers separate themselves by wine-prefix (good for this solution, bad for cut-and-paste ^_^) or not (bad for this solution, good for cut-and-paste). If they do separate, then that also means that if Steam kills its own wine session, it doesn't affect anything else you're running under your normal wine. With this setup, I'd suggest that the relevant steam folder not be deleted on remove, but on purge (or never...). This would put us a step up on the upstream windows installer, which once blew away my gcf files (expected) and my savegames (unexpected) when I uninstalled Steam. >_< There's also the issue of having multiple users accessing the one wine process as a single user. I imaging Wine (in order to implement the Win32 API) doesn't have a lot of protection within a single wine process from a malicious user. So maybe you have to be in a steam-powered group or something to actually fire up this wineprefix. Having said all this, some parts of the above could probably be generalised and added to the Debian Wine packaging, basically implementing a Debian-specific version of the bottling stuff CrossOver (a Wine-derived commercial product) offers, both for packagers and for users. (ie. users can wine-bottle to quickly create or user a wine-prefix under .wine-bottle, and packagers get a dh_winebottle script to create a wine bottle with appropriate permissions and startup scripts) A couple of other things. Wine now includes a Tahoma-replacement, and I don't recalling having that old 26% bug last time I installed Steam, but that could just be my faulty memory. Also, rather than kill -9, wineserver -k should do what you want there, I believe. (ie. tear down the current Wine session) One last thing, I _do_ very much like the postinst stuff you've done. Off the top of my head, I'm not sure that stuff the postinst scripts create (OK, download, in this case, but the difference is immaterial) should go in /usr/share or in /var/lib. (Or /var/cache? Given that the removal of the downloaded cab file or the extracted license agreement doesn't actually break anything, /var/cache might be safe for those...) Wow. That ended up longer than I expected. If you think this is an interesting idea but don't have the time to play with it yourself, let me know (best to directly CC me, I often forget to read d-mentors...) and I'll try and make the time to prototype such a thing for feasibility. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------
Attachment:
pgpEAboDB1ice.pgp
Description: PGP signature