RFC: reducing wasted disk space from addon files

[Jacek Caban]

On 3/27/19 8:05 PM, Alexandre Julliard wrote:
> Jacek Caban <jacek at codeweavers.com> writes:
>
>> Let me put Wine Gecko into design consideration again, mostly because
>> it's simpler and I'd like to preserve that simplicity. Wine Gecko may
>> be considered a just another library in a distro. The fact that it's a
>> PE file is really just an implementation detail. From distro point of
>> view, it may be treated just like any other .so library: just install
>> it into the right place in a shared location. MSHTML would just find
>> and try to use it. If it can be found, no MSI is involved at
>> all. Otherwise the old way is used and installation is not
>> shared. It's both simple and reliable.
> FWIW, I'm currently working on a scheme to allow Wine builtin dlls to be
> built as PE files. Once this is in place, a package could simply drop PE
> dlls in /usr/lib/wine and they would be treated exactly the same as .so
> builtins. Maybe this could make things easier.


That sounds interesting. It would probably make things harder, but 
possibly nicer. There is a long standing bug about library name conflict 
(eg. nss3.dll from Wine Gecko may conflict with one shipped with 
application). If putting them in /usr/lib/wine would mean that whey are 
always visible to the application (like currently our builtins), the 
problem would escalate. Of course the right solution to that is to avoid 
conflicts. It's harder than it sounds, but it should be doable.


Also Wine Gecko contains some data files. They would probably need to go 
to /usr/share/wine or something. I will experiment with it when the time 
comes.


Thanks,

Jacek