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.
- Not care, provide just wine-core package (addon headers are just a
build time dependency). Wine will download and cache addons in runtime.
- 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.
- Use wine-meta-distro to produce both a fresh wine-core and wine
addons package in a single step for a single package.
- 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.
- 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.
- 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