On Thu, 26 Oct 2000, Jeremy White wrote:
>
> After some discussion, this is the end user experience
> we propose:
>
> 1. Installing the package should, IOHO:
>
> A. Install the files to the appropriate place
> (/usr/bin? /usr[/share]/doc /usr/lib/wine)
Obviously... (but where is the appropriate place of things such as
winedefault.reg?)
> B. Modify ld.conf to include the lib directory
This is not necessary. Even the official .deb package was (attempted)
built to not require this. (That it didn't work in the official .deb was
mostly because of glitches on the part of the maintainer...)
In case it's of interest, here's some extracts from the debian/rules file
that's used to build the package (after I fixed the bugs):
build:
$(checkdir)
./configure --with-x --enable-opengl --prefix=/usr --sysconfdir=/etc
--libdir=/usr/lib/wine
$(MAKE) depend
$(MAKE)
touch build
[...]
binary-arch: checkroot build
$(checkdir)
-rm -rf debian/tmp `find debian/* -type d`
install -d debian/tmp
cd debian/tmp && install -d `cat ../dirs`
$(MAKE) install prefix=`pwd`/debian/tmp/usr
libdir=`pwd`/debian/tmp/usr/lib/wine
[...]
#get main libwine into /usr/lib
mv debian/tmp/usr/lib/wine/libwine.so* debian/tmp/usr/lib
mv debian/tmp/usr/lib/wine/libwine_unicode* debian/tmp/usr/lib
[...]
dpkg --build debian/tmp ..
> C. [Controversial] Modify Gnome/KDE file associations
> to associate .exe files with wine
> D. [Controversial] Install a kernel patch to
> allow .exe files to be launched from the command line.
Well, kernel patches aren't necessary. If the user has binfmt_misc in the
kernel, it's just a matter of injecting a descriptor into
/proc/sys/fs/binfmt_misc after boot...
> 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?
> F. [Controversial] Create a global KDE/Gnome menu
> entry for Wine, put Winecfg under it, and maybe
> also put in a simple Windows application launcher.
> Hmmm. This could be cool; we could make a little
> launcher with checkboxes that turn on good
> debug info, and facilitate the creation of a
> decent bug report. Also, the wine launcher
> could control (hide) the stdout/stderr of
> Wine, and give the user an option to see it
> if/when Wine crashes. Thus, the wine launcher
> would be the thing tied to the .exe associations.
Front-ends? Okay, several of those are starting to pop up on freshmeat
already...
> 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).
> 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?
> 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)
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).
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?
