Re: RFS: steam-powered
Paul TBBle Hampson wrote:
> 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...)
>
As Wine gets better and better, we're going to get a lot more Windows
apps made into proper debian packages. We should probably create a
standard for where to put them, as giving each a separate wine prefix
seems like a waste.
> 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.
>
Wine doesn't really work with multiple wineservers running at the
moment. It's on the todo list, but won't make it into Wine 1.0, and
likely won't make it into Wine for a long time after that.
> 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.
>
Indeed, there are some pretty easy ways to screw other wine users on the
same machine, but this is a problem with any application if you both
have write access to the same folder.
> 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)
>
Yeah, wineserver -k hasn't really failed for me even when stuff really
breaks.
> 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.
>
I'd definitely like to take a look at all Wine-related packages as well.
Thanks,
Scott Ritchie
Reply to: