Request for discussion: Using PE libraries for Wine dependencies

[Jacek Caban]

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.


>>> 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?


Jacek