> 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.
> Side issues: With View 2, there is a hope that
> Wine can support a true multiple user configuration.
> Some of us feel that this is not worthwhile to
> try to support at this time.
> Perhaps we resolve this by saying that for debian,
> because of debconf, we take view 2, and for RPMS,
> we take view 1. I hate to diverge, but I think the
> opposing views are pretty entrenched.
I don't see why we can't do this for RPMs.
I am currently using an enhanced wine.ini as our /etc/wine.d/wine.conf
which is not supposed to be modified in the general case.
It does not contain local installation specific stuff, all this is auto-
detected later at first run of wine by a user.
Also in general is the approach to packaging at Caldera to provide a *sane*
preconfiguration of packages if possible, but also do make everything
user changeable.
> 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.
> Remember that packages are not for *us*, they're for end users.
> IMHO, end users really want one of two things:
>
> 1. Wine - to run my app
> 2. Winelib - to build my app
> (okay, no one really wants this yet, but they're
> going to if I have anything to do with it <g>).
Well. I provide an ALPHA version of an emulator for review. The number of
files does not exceed reasonable limits for one package, also documentation
belongs into the same RPM.
I currently do not provide the wine development environment. If I would the
includes and .so files would be in "wine-devel" and the static library (if
there would be any) in wine-devel-static, always depending on size.
Also, documentation is tagged in RPMs, you can option out of documentation
using RPM commandline options.
However, if the docs exceed a certain size (say 2 MB) they could be spun out
into a seperate "wine-doc" RPM.
Spinning off small RPMs is usually trouble in the later run (regarding upgrade
and managebility).
> I think splitting off the doco to save users download time
> is perfectly reasonable, and won't confuse end users.
> However, I think the current split into five, while I
> understand the motive, is confusing to the end user.
Well, we usually do "package", "package-devel", "package-devel-static" and
"package-doc" here, always depending on the size.
> 5. Misc questions
>
> Marcus, what is /usr/bin/winesetup in your package?
It should be /usr/libexec/wine/winesetup really.
It is run if the user has no ~/.winerc (aka 'the first time the user does
wine foo.exe') and does:
- look for mounted dos partitions, find the windows one, find
the windows directory.
- copy /etc/wine.d/wine.conf, change Path to [Drive W] to be
set to the windows directory.
- create some directories in the users homedir, which will be [Drive C]
later. Create ~/windows and ~/windows/system.
- symlink .exe, .dll, .drv files from real windows dir and real windows
system dir to ~/windows/, ~/windows/system.
This allows latter package installations for the user without
destroying the original Windows config, but with reusing all its
files transparently.
(You can exchange "original windows dir" with "unix based windows
dir" if you want to. Or use both.)
Ciao, Marcus
