Request for discussion: Using PE libraries for Wine dependencies

[Zebediah Figura]

On 4/13/20 8:04 PM, Jacek Caban wrote:
> On 13.04.2020 22:47, Zebediah Figura wrote:
> 
>>>>>> I don't know what we'd do about Mac, but along the same lines, I'd
>>>>>> think we'd want to extend/analogize the current solution regarding
>>>>>> bitness to the whole architecture triple.
>>>>> Well Mac would be even easier to target than it is now if we provide
>>>>> right tools (because some of those dependences are tricky on Mac
>>>>> already). And if some packagers really insist on splitting those
>>>>> packages, they can still do that. with what I proposed. They can 
>>>>> use our
>>>>> build system as a 'driver' or do it manually, that's all fine. We'd be
>>>>> not forcing one way or another.
>>>>>
>>>>>
>>>>> So let me give a few examples of different choices packagers can do. I
>>>>> will call wine-core Wine as we know today (which will not change
>>>>> architecturally) and wine-meta-distro the proposed separated repo for
>>>>> dependencies build system allowing a simple and straightforward way to
>>>>> bootstrap complete Wine+dependences package, depending only on cross
>>>>> compilation tools.
>>>>>
>>>>>
>>>>> 1. Not care, provide just wine-core package (addon headers are just a
>>>>> build time dependency). Wine will download and cache addons in 
>>>>> runtime.
>>>>>
>>>>> 2. Use wine-core the way distro currently do to provide Wine package.
>>>>> Use wine-meta-distro to build Wine addons as one but separated 
>>>>> package.
>>>>>
>>>>> 3. Use wine-meta-distro to produce both a fresh wine-core and wine
>>>>> addons package in a single step for a single package.
>>>>>
>>>>> 4. Like 2 or 3, but distro wants some customization itself. They 
>>>>> can do
>>>>> that, for example, by pointing wine-meta-distro to its own version of
>>>>> relevant package, pass additional config options or do simple source
>>>>> code modifications.
>>>>>
>>>>> 5. Split Wine into 20 packages. A distro can use wine-meta-distro 
>>>>> to do
>>>>> build config stuff, so that they don't need to change their scripts
>>>>> every time something changes in any of dependent packages, but 
>>>>> otherwise
>>>>> treat every dependency as a separated package.
>>>>>
>>>>> 6. Split into 20 packages and deal with them without wine-meta-distro
>>>>> packages. This will require packagers to redo all the work that
>>>>> packagers choosing 1-5 will be getting for free.
>>>>>
>>>>>
>>>>> Your proposal seems to be similar to something between 5 and 6. I 
>>>>> don't
>>>>> expect packagers to be thrilled with that idea if they have 2-4 as
>>>>> alternatives, by the key point is: let's give them a choice.
>>>> Pretty much 5, I think. If I understand correctly, 6 is only true when
>>>> distributions are already shipping mingw packages (and only for those
>>>> packages), in which case they're not really redoing any work.
>>>
>>> The other important part of 5 is that you can build all those packages
>>> in a combination of versions that are tested and guaranteed by community
>>> to work (unless packager chooses to do otherwise). My understanding is
>>> that you meant packagers to do arbitrary version choices by default.
>> I'm not admittedly sure what's meant by arbitrary version choices, or
>> perhaps this paragraph in general, but I'm imagining that mingw packages
>> will be no different than non-mingw packages in most respects, so
>> we/distributions can do whatever testing is desired.
> 
> 
> If you expect packagers to build 20 packages, they need to make 20 
> version choices about version and then update them as they see the fit.

Maybe, but the alternative is "let the Wine project make all of those 
decisions". And if they'd rather trust the versions we propose, then it 
wouldn't matter how the packages are built.

>>>> 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).

If one insists on compiling everything themself, they'd go through the 
same process as they would with any other package. 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.

> Jacek
> 
>