[MacPorts] #64681: wine: Update to version 9.x

[MacPorts]

#64681: wine: Update to version 9.x
-----------------------------------------------+----------------------
  Reporter:  syurin-nagatuki                   |      Owner:  Gcenx
      Type:  update                            |     Status:  assigned
  Priority:  Normal                            |  Milestone:
 Component:  ports                             |    Version:  2.7.1
Resolution:                                    |   Keywords:
      Port:  wine, wine-devel, wine-crossover  |
-----------------------------------------------+----------------------

Comment (by ryandesign):

 Replying to [comment:38 thetrial]:
 > For me it was always a unique point of MP, that even very old OS had the
 possibility to use new(er) tools.

 It still is. Many ports can still be used on older OS versions. However
 sometimes developers decide to drop support for older OS versions by using
 features that only exist on newer OS versions. In that case, it's not our
 job to second-guess them nor to independently develop and maintain large
 patchsets to reintroduce support for things the developers no longer
 support. Sometimes continuing support for older OS versions is easy for
 us, for example through our legacy support library.


 > Regarding the +universal-thing: I thought that further wine could get
 ridd of this +universal obligation. Isn't it possible to have a pure Intel
 build? At that time +uiversal meant PPC/INtel, or am I wrong? In the
 meantime ARM came along.

 Universal, as you see when you run "port variants", means "Build for
 multiple architectures". Which architectures is defined in your
 macports.conf file. On Mac OS X 10.4 and 10.5, the default value is "i386
 ppc", meaning 32-bit Intel and PowerPC. On Mac OS X 10.6 through macOS
 10.13, the default is "i386 x86_64" meaning 32-bit and 64-bit Intel. You
 cannot build universal with MacPorts on macOS 10.14 or 10.15. On macOS 11
 and later, the default universal architectures are "arm64 x86_64" meaning
 64-bit Intel and ARM.

 Wine is and always has been Intel-only software. It used to be 32-bit
 only. Then a 64-bit version called wine64 was created, however it requires
 the 32-bit version of wine to be installed. And you must use the 32-bit
 version of wine if you want to run 32-bit Windows software and the 64-bit
 version of wine for 64-bit Windows software. While Apple started its
 transition to 64-bit in Mac OS X 10.4 and finished it with the removal of
 the ability to run 32-bit software in macOS 10.15, my understanding is
 that 32-bit software has remained ubiquitous on Windows for much longer,
 so that it remains important to be able to run 32-bit Windows software
 today. To accommodate macOS 10.15's inability to run 32-bit software, the
 developers of Crossover created a method of running 32-bit Windows
 software within a 64-bit executable, which they called wine32on64. With
 this new method, dependencies only need to be 64-bit Intel. However they
 only supported this new method on macOS 10.15 and later; older macOS
 versions needed to continue to use the old real 32-bit wine executable to
 run 32-bit software. Therefore installing wine on older macOS (if the
 MacPorts ports are ever enhanced to allow that again) will continue to
 require dependencies to be universal (32-bit and 64-bit Intel).


 Replying to [comment:45 thetrial]:
 > I’m not sure why the ports are not divided into possible and impossible
 updates under Sierra,

 Ports should indicate which OS versions they work on. wine-devel, for
 example, indicates that it works on macOS 10.15 and later (the line that
 reads `platforms {darwin >= 19}`). Most contributors test on a recent
 version of macOS and don't notice when some update causes a port no longer
 to build on older OS versions, so some ports don't indicate it when they
 should. If you find a port that doesn't build, you file a bug report, and
 hopefully someone can investigate the cause of the problem. If it can be
 fixed, hopefully it will be. If it is determined that the problem is that
 your OS is too old, then the port can be updated to indicate that.


 Replying to [comment:51 thetrial]:
 > But this +universal hassle was a very big anklet. Really disturbing.

 I don't know how to respond to statements like that. We try to respond to
 bug reports. What else would you have us do? If you expect all ports in
 MacPorts to be 100% correct 100% of the time and never to encounter any
 build failures, that would be nice but isn't achievable. In the time it
 takes me to fix a bug in on port, undoubtedly several new bugs will have
 been introduced in other ports.

-- 
Ticket URL: <https://trac.macports.org/ticket/64681#comment:52>
MacPorts <https://www.macports.org/>
Ports system for macOS