Jeremy White wrote:
> Okay, part two is to discuss what an RPM or DEB installation
> process looks like to the end user.
>
> 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)
Don't forget to use /etc or maybe /etc/wine instead of /usr/local/etc.
>
> B. Modify ld.conf to include the lib directory
I thought the rpath stuff was supposed to avoid that. Although my install
is still in /usr/local/lib like it has always been, and /usr/local/lib is in
my /etc/ld.so.conf. You could just install in /usr/lib like most other
programs.
>
> C. [Controversial] Modify Gnome/KDE file associations
> to associate .exe files with wine
Hmm, that's a good idea, but I would only do it if you can just drop a file
in a directory. If you have to use a lot of script magic then don't bother.
>
> D. [Controversial] Install a kernel patch to
> allow .exe files to be launched from the command line.
Mucking with the kernel should be out of the scope of any programs package.
Make it a seperate package if you want. See
http://www.thecomputerbuilder.com/~dfe/linux/kernel_RPM/ if you want some
ideas.
>
> 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.
I would say use %config(noreplace) on /etc/wine.conf or /etc/wine/wine.conf
if you are making a seperate directory in etc. Install a reasonable config
file by default so that first time installs will get a config file.
Existing installs will never have the file replaced.
>
> 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.
>
This would be better packaged seperately from wine. Along with item C now
that I think about it.
>
> G. [Optional, not a good idea IMHO] Run Winecfg.
>
Definitely not on an RPM, that is a bastardization of the postinstall
script. From what I hear that would be lame for a .deb to do as well.
>
> H. Print a message telling them what to do next
>
Notifying the user of the need to change the config is probably a good thing
unless it is completely automatic, which is probably a bad thing.
>
> They should be instructed to install the package as
> root, and then exit, just as you normally do for
> package installation.
>
> 2. As a regular user, they will have several choices:
>
> A. They can run winecfg directly; it will create
> their ~/.wine directory, and create their
> ~/.wine/config and registry files.
> B. They can find a .exe with their Gnome or KDE
> file manager, and double click on it to start Wine
> C. [Okay, now I'm pushing my luck] They can find their
> .exe in an xterm, and type 'foo.exe' to have it
> auto launch.
> D. The old fashioned approach: Run wine from the console
>
These all sound fine.
>
> 3. When Wine is run for the first time, and doesn't find
> a ~/.wine/config file, it will:
>
> A. Check for a /etc/wine.conf config entry along the
> lines of 'app_to_run_when_no_winerc', and launch
> that app (presumably winecfg).
> B. Winecfg would populate ~/.wine correctly.
> C. [Controversial] IMHO, there should be no global
> /etc/wine.conf file, and the 'app_to_run_when_no_winerc'
> setting should be set to winecfg by default.
>
I don't know if I like any of these. With small changes to the wine code we
could actually have a global wine configuration file which IMHO would be
much more usefull than a hack to create individual user config files on the
first wine startup for a user. The user would still have the option of
running wineconfig themselves to personalize their configuration.
>
> 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.
>
I wouldn't go that far. I'd say that it should be done much sooner than
that, but first lets concentrate on basic packaging.
>
> There is a lot of good work that is done in wineinstall,
> and it should be merged into this process.
>
Yes, I have thought this several times. Wineinstall should be changed to a
post-installation configuration tool. Something that can be run by a user
or by the administrator after the wine package has been installed.
-Dave
