[snip]
> > E. [Controversial] Do *not* install a /etc/wine.conf
> > file. IMHO, since the global wine configuration
> > is IMHO misleading, we shouldn't install one by
> > default.
>
> Misleading? Care to elaborate?
AFAIK, the global wine configuration has no effect if
you have a local .winerc. Since I think almost everyone
will run with a ~/.winerc (so the Wine settings can
be tweaked at user level, not by root), I feel that
is misleading.
I do, however, think it's a great idea to have
a /etc/wine/wine.conf.default (along with the
default registry files).
[snip]
> > G. [Optional, not a good idea IMHO] Run Winecfg.
>
> It would be best if post-installation configuration steps could be
> integrated with the distribution's configuration-question facilities
> (debconf).
Agreed. Doesn't really help the RPM side of the univere,
though - AFAIK, there's no equivalent for RPMs.
>
> > H. Print a message telling them what to do next
> >
> >
> > They should be instructed to install the package as
> > root, and then exit, just as you normally do for
> > package installation.
>
> Are you telling me it's possible to install a distribution package without
> being root? And why should the end of a package installation process be to
> tell the user to install the package again?
Sorry, I've obviously confused the issue.
Take what I meant to say as
Of course, they will have installed as root, and
so now we should tell them how to run Wine as a user.
>
> > Now, there are a some things that we have *not*
> > addressed in this proposal. We haven't tried
> > to realistically address multi user installations,
> > or provide for shared registry files. IOHO, that's
> > best left for Wine 1.1.
>
> Why's that? It can't be harder to do than agreeing on a clean design and
> writing a couple of lines of code... the current registry model would only
> require minor tweaks to enable registry sharing (except that Alexandre
> broke wine.userreg saving recently)
Well, part of it is that I haven't fully followed
the registry conversation, and so, since I don't understand
it, it must not be possible <grin>.
As a consequence, I should defer discussion of this to
others. However, aren't there issues with language
selection and arbitrating shared access to registry files
that are going to be hard?
>
> I think a package should provide:
> - basic Windoze directory structure, containing stuff like win.ini,
> system.ini, and some empty .dll files that apps need
> (the official .deb package put Drive C into /usr/share/wine/drivec)
> - global wine.conf that lets e.g. Drive C or S or W or whatever point to
> the basic Windoze structure, and Drive H or C or whatever point to
> ${HOME}
> - global registry with the registry keys most apps need (maybe linked to
> root's registry?)
> (how much of these can be autogenerated as a postinstall operation is yet
> to be decided)
>
> Wine should be fixed to create the necessary HKEY_CURRENT_USERS from the
> global registry, as already discussed on wine-devel... but the
> HKEY_LOCAL_MACHINE doesn't have to be per-user... and many apps do need
> HKEY_LOCAL_MACHINE stuff (or perhaps particularly HKEY_CLASSES_ROOT).
See, and I think that all of this should be (and is
currently) done by winecfg, and that all of these
files should go under ~/.wine/drivec. AFAIR, having
a drive C that is not writable (as per /usr/share/wine/drivec)
has triggered know bugs in Wine.
IMO it is a mistake to attempt to create a working
wine.conf file without asking the user the most critical
Wine configuration question: Do you want to use your Windows
partition or not? I believe that user complaints and
questions can be drastically reduced by forcing this step.
>
> Perhaps we want to add a /etc/group entry for wine to restrict access to
> the package's Windoze directory structure, and make that directory owned
> by the wine group?
Hmm. That sounds like a good idea for addressing the
multiple user stuff...which I'm not qualified to discuss...nevermind.
Jer
