> > 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.
> - 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?
> 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).
ok, let's summarize a bit:
?) support multiuser? i vote no for this time.
?) have interactive package installation? i'm not completely sure about
this, but i prefer "yes". maybe becouse i'm used to it from windows.
?) what tools to pack in? (i vote yes :-)
?) registry *.exe files with common desktops? i vote yes.
?) 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.
?) provide integrated front-end to launch wine application? i vote yes.
?) modify /etc/ld.so.conf file? i vote yes - but do it smart.
forgot something?
martin
