[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: steam-powered



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: pgp3sSbHM5V54.pgp
Description: PGP signature


Reply to: