Le dim 15/08/2004 à 00:21, David Lee Lambert a écrit :
On Wed, Aug 11, 2004 at 04:45:20PM +0200, Henning Gerhardt wrote:
Hi Mike, you wrote:
I'm not sure what to do about this, except maybe to add back in support for ${HOME} style vars. It's clear that people are "using" (at least, installing) much older versions than we anticipated.
Personally I would prefer to merge back the support for ${HOME} variables because I think many other people have the same problem if they want to upgrade wine.
Not having totally grokked the code, I think this raises an important semantic issue: if ~/.wine/dosdevices and the config-file's text conflict, which has priority? Or should Wine read the config-file and then (effectively) overwrite the settings with the contents of ~/.wine/dosdevices? This won't work if Wine automatically builds ~/.dosdevices from scratch.
Only ~/.wine/dosdevices is used now. The drive sections in the config is used to build dosdevices if it doesn't exist, then it is read back as if existed before.
It seems that mapping one drive to the user's home directory is a common case, since many organizations already do this for users via Samba or Netware. As presently implemented, is there any reason a system administrator shouldn't do
( cd /etc/skel ; mkdir -p .wine/dosdevices ; cd .wine/dosdevices ; ln -s f: ../.. )
where f (for example) is the drive letter used for each user's home directory, and then use a shell script to push the change out retroactively to existing accounts?
That will probably cause some problems with the way we currently detect whether or not to lauch wineprefixcreate, which is the existence or not of ~/.wine. You should customize your version of wineprefixcreate if that's what you want to achieve (but it won't be applied to existing ~/.wine dirs, that'll need to be taken care of in another manner. Updates to ~/.wine between versions are not very well managed right now in Wine.).
Vincent