Martin Pilka 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?)
>
> it's related to Wine configuration, and every user should have access to
> it, so i guess /etc/wine/winedefault.reg. but: are we going to
> distribute regapi tool as the part of the package? or, generally: what
> applications should we pack in?
>
> > > 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...)
>
> well, if we are puting .so files under /usr/lib/wine directory, ldconfig
> have to know about it...adding line /usr/lib/wine to /etc/ld.so.conf
> file and run ldconfig after that is probably required in order to have
> wine "ready-to-use" after installation.
>
> > > C. [Controversial] Modify Gnome/KDE file associations
> > > to associate .exe files with wine
>
> i think the packaged (or "bottled"? :-) Wine should be as much user
> friendly as possible. the man on the other side is the "normal user",
> and this is working for his convenience.
>
> > > 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...
>
> is the "binfmt_misc" option switched on by default?
>
> > > 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).
>
> the question is what this post-install steps should include. should they
> generate the complete Wine configuration (like wine.conf, registry
> settings etc.)?
>
> > 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)
>
> maybe the package should contain the directory like
> /etc/wine/fake_windows_template which will include the windows structure
> you mentioned. then for example when user will decide to install another
> fake windows installation, he can just copy that directory to right
> place. or we can provide just some tools which will be able to generate
> this directory structure.
>
Why in the world would you put a fake windows template drive into /etc ???
That kind of stuff belongs in /usr/share/wine or /var/wine. I prefer
/var/wine. Actually, I am working on this right now.
>
> > - 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}
>
> it's not easy to generate *good* global configuration file and you'll
> need some answers from user to do that. should be that questions part of
> the package installation?
>
Actually, I think with some tweaking of wine code we will be able to do good
global configuration files and not need a per-user .winerc unless the user
wants to change around his/her drive letters for some reason.
>
> > 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?
>
> are we going to support multi-user configuration? this question has the
> serious impact on packaging.
> if-yes) how long it will take us to prepare Wine to support this?
>
> i'm not sure if we should support multiuser configuration right now.
> that could make things easier for us at this time - some message like
> "log as a user, and run this tool to generate your local ~/.winerc file
> before you run wine" on the end of installation process, and that's it.
> when Wine will be ready for multiuser, we can change also packages to
> support it. i have a feeling that could take some time (maybe i'm
> wrong).
>
Make the package without multiuser configuraton first and get it out the door,
because Wine is in desperate need of a halfway-decent RPM. Then go back and
setup wine for multiuser configuration.
>
> ok, let's summarize a bit:
>
> ?) support multiuser? i vote no for this time.
not for now, but very soon.
>
> ?) have interactive package installation? i'm not completely sure about
> this, but i prefer "yes". maybe becouse i'm used to it from windows.
hell no. The package should refer the user to running wineconfig or whatever
and not muck around with the configuration by itself.
>
> ?) what tools to pack in? (i vote yes :-)
Yeah, good idea.
>
> ?) registry *.exe files with common desktops? i vote yes.
this might be better suited to a seperate package that contained a frontend to
running wine, I vote no on this one for now.
>
> ?) support *.exe execution directly from command line? i vote yes, as
> far as it is so easy like create some file under
> /proc/sys/fs/binfmt_misc directory.
This involves creating a file in /etc/rc.d/init.d with appropriate chkconfig
information that responds to start by using proc to enable windows binary
loading, and stop by using proc to disable windows binary loading.
Restart/reload should just do a start. System admins could easily configure
which runlevels to run this in and therefore set up the system however they
want.
>
> ?) provide integrated front-end to launch wine application? i vote yes.
Not in this package, use a seperate package.
>
> ?) modify /etc/ld.so.conf file? i vote yes - but do it smart.
>
No, it's not necessary with new versions of wine as Ove pointed out.
-Dave
