wine-gecko/mono packages (Re: RFC: reducing wasted disk space from addon files)

[Jens Reyer]

On 18.03.19 03:45, Vincent Povirk wrote:
> On Sun, Mar 17, 2019 at 4:11 PM Jens Reyer <jre.winesim at gmail.com> wrote:
>>
>> On 06.03.19 22:21, Rosanne DiMesio wrote:
>>> FYI, it's been on my todo list to add wine-mono and wine-gecko packages for WineHQ. I already have ones for Fedora on the OBS, though we're not officially distributing them yet (still need to create Debian/Ubuntu ones). All they do is install the prebuilt .msi files to /usr/share/mono and /usr/share/gecko.
>> I'd suggest for winehq wine-mono/wine-gecko packages to install to /opt,
>> not /usr.  Otherwise you'd quickly run into the need for new lists of
>> "Conflicts:" and similar.
>>
>> For this to work I think we just need to slightly adjust
>> dlls/appwiz.cpl/addons.c.  Vincent already referenced in another mail
>> the comments found there:
>>
>>     /*
>>      * Try to find addon .msi file in following order:
>>      * - directory stored in $dir_config_key value of
>> HKCU/Software/Wine/$config_key key
>>      * - $datadir/$addon_subdir/
>>      * - $INSTALL_DATADIR/wine/$addon_subdir/
>>      * - /usr/share/wine/$addon_subdir/
>>      * - download from URL stored in $url_config_key value of
>> HKCU/Software/Wine/$config_key key
>>      */
>>
>> So maybe just add code for /opt/$addon_subdir/ before "download"?
>>
> There's no conflict. The wine-mono and wine-gecko packages can just
> install into /usr/share/wine as Rosanne explained regardless if which
> Wine version, if any, is installed there. The msi filenames include
> the version number, so all versions can theoretically coexist there.
> The Wine packages can then just depend on (or recommend/suggest) the
> versions they need.
> 

Thanks Vincent.  Yes, you are of course right about the Wine side of
this issue.  But at least the Debian package manager dpkg will error out
if e.g. there's ever a wine-mono package from Debian with the same
filename in the same location as installed by a winehq wine-mono package
 (unless they have identical checksums which they won't have because
Debian rebuilds from source).

To avoid this either don't use the same pathname (my suggestion), or
tell dpkg that 2 different packages install different files with the
same pathname by adding "Conflicts:$NameOfDebian-wine-mono-Package" in
the winehq wine-mono package's debian/control.

I think the FHS also mandates vendors to use /opt.

Greets