[MacPorts] #60431: base: (linux) fails to determine build arch correctly

[MacPorts]

#60431: base: (linux) fails to determine build arch correctly
---------------------+--------------------
  Reporter:  kencu   |      Owner:  (none)
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  base    |    Version:
Resolution:          |   Keywords:  linux
      Port:          |
---------------------+--------------------

Comment (by RJVB):

 Ken, I have not forgotten about this, have been bringing my `base` install
 (and thus my MacPort-devel port) up-to-date and polishing things up here
 and there. I can now also install `base` via dpkg on Mac, so reverting to
 a previous install is more straightforward (I asked about up/down-grading
 with the native Mac packages on the ML but missed any answers I might have
 gotten).

 With that off my chest I'll try to find some time to look at the tickets
 you mentioned, but feel free to have a look at my various patches. I do
 have a number of patches that are not applied on Mac, but that's mostly to
 keep the installed code clean on Mac.

 It might not be a bad idea keep this kind of separation if not everyone on
 the team is fine with the idea of having a single code base that works on
 both platforms. This could also send a clearer signal to potential users
 that they should expect to be able to install just any port "as is". There
 are a lot of patches (and Portfile operations) in the ports tree that
 introduce unconditional Mac specifics, and the chance of running into
 conflicts with (esp.) headerfiles installed through the distribution is
 much bigger. It happens quite regularly that I need to uninstall distro
 `-dev` packages, or worse, to remove crucial components from them by hand
 because uninstalling would also uninstall other packages that I don't want
 to uninstall for some reason. There's also an issue with rpaths; meson has
 a knack of stripping the carefully tuned settings I added from the final
 binaries, which means a wrapper script is necessary. There's also a lot of
 trickyness going on with GLib, GTk3 and Vala. I don't think they're really
 designed to support having a newer version in a parallel prefix (gentoo-
 prefix might have an answer to that).

 In practice, my Linux-specific ports tree is a bit of a cardhouse of ports
 with dropped dependencies that are expected to be provided through the
 system (mostly because of lazyness and not having to build and have them
 doubly installed) or that are actual wrappers for things installed in the
 system (the llvm and clang ports, for instance).

 Have you looked into a replacement for the machista library? This is about
 the only function from `base` that does not currently work under Linux.
 Not that I really miss it, most of the time, so I haven't tried to come up
 with a replacement myself.

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