From: "Jeremy White" <[EMAIL PROTECTED]>
> 1. At package install time, should we create a
> global wine.conf?
>
> View 1: No - we supply something like
> wine.conf.template, and then walk
> the user through using winecfg of wineconf
> to get their own .winerc.
>
> View 2: Yes. We autobuild a global wine.conf
> file during the install process.
> With debian, we can do this somewhat
> elegantly due to debconf.
There is not much difference between these two: even in the
second case, if the user wants to customize some of the
settings, he will have to copy the global file into their own
.winerc file. In other words, the two cases are almost the
same, the difference being that in the second one we do the
copying lazily.
I would say the issue is wether or not we inherit settings
from the global file or not.
>
> 2. (Not yet discussed) - What packages do we provide?
>
> Marcus provides one - Wine.
>
> Ove provides five - libwine-dev, libwine, wine-doc, wine-utils,
> and wine.
>
> I would argue that Marcus provides too few, and that Ove
> provides too many.
True. I agree with your suggestion, but I don't like the names. The current
naming convention is to use -devel for the development package, so I
would say:
wine -- for end users, would allow to run winelib/win32 apps
wine-devel -- for developers of winelib apps
> 3. Concern - winecfg dependencies
>
> When designing winecfg, we chose Tcl/Tk, partly because
> that's what TkWine used, and we were trying to expand on that,
> and partly because we didn't have a clear alternative.
Python would have been so much nicer...
6. With/without a windows installation
I think we should have a script that would allow the user to easily change
between a configuration pointing a windows installation and one without a
real windows install. Basically this idea can be generalized in a number of
ways, but the idea is to allow the user to make this sort of change very easily.
--
Dimi.
