multi-ask

[chilli.namesake at gmail.com]

Hi mailing list participants. 

I'm going to introduce several topics. At your choice, leisure and convenience, a response to any is appreciated. 

1) First of all, as a user, I am tremendously grateful to all the macports developers. MacPorts is really great stuff. Well done.


2) I wrote a simple script to build and install all the ports I usually install, and I was astounded that, after about 12 hours, it completed successfully without any build errors. This is on a Late 2012 Mac mini running Mojave. To be clear, I was surprised my script worked rather than that macports works (I knew that already). 


3) Running same script on mid 2011 Mac mini running Mountain Lion also completed successfully, but by the time the script completed, there were updates. Specifically, advancemame was listed as out of date, like this:

advancemame                    3.9_0 < 3.9_0  (C++ stdlib libstdc++ != libc++)

I run port -vsN upgade outdated, and the build ultimately fails with the message:

advancemame is using libstdc++ (this installation is configured to use libc++)
Error: Port advancemame is still broken (cxx_stdlib mismatch) after rebuilding it more than 3 times.

I doubt Mountain Lion is still supported, and I'm not sure I care too much as I am running advancemame @0.106.1_0 on a 2010 MacBook Pro with a macports install I am no longer updating, and it works just fine. 

But I thought I'd ask why the 2011 Mac mini Mountain Lion port build for advancemame is choking.


4) On both the 2011 and 2012, no matter what I set the macports.conf build_arch to (x86_64, x86_64 i386, or i386), I can't get either baskiliskii or sheepshaver to build. Regardless of port or build_arch (in this example, i386) the error is

Error: basiliskii cannot be installed for the configured build_arch 'i386' because it only supports the arch(s) 'i386'.

I get the same errors with sheepshaver, which is somewhat confounding. Any information regarding this puzzle is appreciated. 


5) Here's where I go off the rails and likely show considerable ignorance. I really can't stand homebrew. I neither appreciate the metaphor nor what a mess it makes, and I never cared for fanaticism or penquinistas. However, there are a number of more recent versions of packages maintained on homebrew of the same earlier version package on macports, and a number of packages on homebrew unavailable on macports. So the idea (possible Req:) is this: reverse engineer homebrew packages to install through macports and incidentally in the process of rolling homebrew packages into macports, fix what is broken in homebrew, have the packages install the macports-way and be available for management and updates through macports and without wasting resources with any dedicated macports maintainers for homebrew packages. I'm not sure how this could be implemented, and I certainly don't want a marriage of macports and homebrew, nor an emulation layer for homebrew in macports, but more like the macports assimilation of homebrew packages with nothing at all changing with the macports interface. Maybe all homebrew packages would just be listed as a separate macports category "(homebrew)," if that doesn't cause too much confusion with properly categorized ports at a different version. What do you think of that? Possible? Worthwhile? Granted, this idea is not completely formed, but ultimately the goal is to reveal homebrew for what it really is, a sloppy and superfluous package manager. 



Any replies, answers, explanations, criticisms and insults appreciated! 
Thanks for everything!

Kind Regards,
Chilli