Request for discussion: Using PE libraries for Wine dependencies

[Jacek Caban]

On 14.04.2020 04:27, Zebediah Figura wrote:
> On 4/13/20 9:16 PM, Jacek Caban wrote:
>> On 14.04.2020 03:35, Zebediah Figura wrote:
>>>>>>> I don't work in distributions, but I don't particularly 
>>>>>>> understand why 5
>>>>>>> is any harder than 2-4, or what's gained from having 2-4 as an 
>>>>>>> option.
>>>>>>
>>>>>> The gain from 2-4 is simplicity that I mentioned earlier, which I 
>>>>>> think
>>>>>> is crucial if we want wide adaptation. What's gained by 5?
>>>>> Essentially, that it's the way things are already done.
>>>>>
>>>>> I guess I'm also still not understanding why 2-4 is simpler, except I
>>>>> guess it doesn't require any packages to be installed as build
>>>>> dependencies—which doesn't seem like a huge advantage, since that's
>>>>> basically just the norm for package building.
>>>>
>>>>
>>>> Let's use an example. Suppose I want to bootstrap a fully working 
>>>> Wine on a distro with no Wine or Wine-specific packages (or I just 
>>>> don't want to use them). I don't want to use any binary blob, so I 
>>>> need to build all PE dependences myself. How would my experience 
>>>> look like with what you propose?
>>>
>>> Well, in general, someone like me who's not interested in hacking on 
>>> any PE libraries would retrieve precompiled libraries from WineHQ or 
>>> distribution repositories—just like installing regular devel 
>>> packages, just with a different architecture—and then build Wine the 
>>> same way as is currently done (configure, make, make install).
>>
>>
>> So, well, binary blobs.
>>
>>
>>>
>>> If one insists on compiling everything themself, they'd go through 
>>> the same process as they would with any other package.
>>
>>
>> I guess that answers your question about why 2-4 is simpler. This is 
>> not as much about insisting as those are real challenges that may be 
>> potentially faced by forks like Proton, CrossOver or any other.
>
> I'm moderately familiar with the build process for Proton, and I don't 
> *think* it would actually be necessary to build any packages, provided 
> that our mingw libraries can be installed in the host VMs.


That's a possibility, but I don't consider that to be nice nor 
technically correct solution.


> I'm not familiar with the build process for CrossOver, though. But if 
> CrossOver—or any similar software—doesn't build and distribute all of 
> those libraries already, then would it be possible to depend on mingw 
> libraries in the same way that it depends on linux libraries? Failing 
> that, could they distribute .deb &c. files directly, or even .dll 
> files copied from our mingw packages? (Much like a Windows program 
> would.)


I don't think analysing existing build systems is relevant here, they 
are not yet facing the situation we will put them in. By making sure 
that they can easily replicate what upstream Wine does we can ensure 
that they are able to reuse upstream Wine work. They may choose to use 
it or not.


>>> I don't see why wanting to manually compile every PE dependency 
>>> would be any more likely with Wine than other software, or why it 
>>> should be treated any differently. 
>>
>> We will have to agree to disagree on that. In my opinion expectation 
>> to provide SDL2 shared by thousands application is something 
>> different than Wine expecting distros to provide an independent cross 
>> compiled SDL2 package of acceptable version specifically for Wine.
>
> Which is why I'm not really looking at it from the perspective that we 
> should expect distributions to build those packages rather than the 
> Wine project. 


Yes, that explains differences in opinions. I try to ensure that needs 
of broader Wine community are taken into account and I think that both 
distros and forks are important parts of the community.


Jacek