On 9/9/21 2:05 PM, Jan Engelhardt wrote:
On Thursday 2021-09-09 18:23, Zebediah Figura (she/her) wrote:
[The] assumption has been made even without considering the whole renaming-dynamic-libraries problem (after all, what possible users could there even be for MinGW libraries in the first place?)
The downstream uses for mingw libraries are
- the WSL loader for our distro - other mingw packages (usually more libraries) - to build other kinds of software that do not participate in openSUSE anymore (i.e. some application you're trying to ship to a customer with native Windows)
In that sense, the mingw stack's importance ranks a little below that of dmd/fpc.
Sorry, what are dmd/fpc?
Of course, the other bit is, *maybe* it's possible to use unmodified dynamic libraries. There's been ideas proposed and we're still trying to work out the kinks and figure out if it's actually plausible. In a sense I kind of want to ask "assuming we can, what do you want, and assuming we can't, what do you want".
Un-bundling is high on the list, even if the code is only ever used by one entity. Think of an extreme like chromium, which currently tries to compile 40000-ish source files from one source tarball. If one fails, the entire RPM build aborts naturally, and it has to painstakingly restart from zero after the build recipe was modified in any way. In short, the metric "source files compiled per .spec" should not be too large.
(Think back to when Xorg 7.x was being split up into libxcb, libX11, libXwhatever. Though we now have 20+ more spec files, the turnaround time is _so_ much better than what it once was.)
Sure, makes sense. Although honestly the size of Wine's dependencies is not particularly comparable to the size of Wine itself (not that that's great either, but, well.)