Re: Misconceptions about binaries (was: Re: Desolate Condition)

[Ryan Schmidt]

On Apr 3, 2021, at 19:21, Wowfunhappy wrote:
> 
> I know it's just one data point, but I thought the replies I got on this 
> Hacker News comment today were interesting. I can understand why he/she got 
> confused, and I wonder if there's anything MacPorts could do to make it 
> clearer. https://news.ycombinator.com/item?id=26678498

Thank you for trying to tackle the issue. I'm also reminded of:

https://xkcd.com/386/

Re: Desolate Condition

[Ryan Schmidt]

On Apr 5, 2021, at 13:04, Karl-Michael Schindler wrote:

> 2) Put the command 'port install PACKAFE_NAME' to a prominent position.

https://github.com/macports/macports-webapp/issues/144

Re: Desolate Condition

[Nils Breunese]

Karl-Michael Schindler  wrote:

> This indicates the first problem: Brew is often better represented on 
> homepages of other software than MacPorts. The task to tackle is to find a 
> person or form a team going after this.

A more scalable solution would be for port maintainers to check the upstream 
docs for the ports they maintain and contribute a snippet on how to install the 
software via MacPorts if not already present. Usually all this takes is a 
simple merge request. I think this is a great idea and I’ve been doing this for 
my ports.

Examples from the Spring Boot documentation: 
https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started-macports-cli-installation

People will even start copying these MacPorts installation instructions into 
blog posts and educational materials.

Examples of ’sudo port install kotlin’: 
https://www.google.com/search?q=%22sudo+port+install+kotlin%22

Apparently it was even copied into an O’Reilly book: 
https://www.oreilly.com/library/view/kotlin-programming-by/9781788474542/86027be9-71a7-4afc-8354-51fceeb741d9.xhtml

Nils.

Re: Desolate Condition

[Karl-Michael Schindler]

Am 05.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
> 
> To: MacPorts Developers 
> Subject: Re: Desolate Condition
> Message-ID: 
> 

Hi.

I think that the topic installing binaries or not points to a more general 
issue, namely public relations. MacPorts could improve a lot on this. For 
example by touting how many packages can be installed as binaries now. In 
addition, how many packages are offered by macports as well as things like what 
categories have the most installs or the most new packages or the most updated 
packages. I am fully aware that this sounds silly to some point. But in order 
to compete with homebrew, improving on technical aspects is not sufficient. 
Categories are a particular strength of MacPorts vs homebrew.

Asking friends, why they use brew instead of macports and their answer was, 
because it is easier to use. I said: 'What?' because what is the difference 
between brew install … and port install … ? But after looking a bit more into 
the details, the case of installing ImageMagick as a first time user turned out 
to be more revealing than expected:

So, from google your first hit is https://imagemagick.org. Going to 'Download' 
and 'Mac OS X Binary Release' gives you a page where you find 'brew install 
imagemagick' very prominently, but only a link for the homepage of MacPorts. 
This indicates the first problem: Brew is often better represented on homepages 
of other software than MacPorts. The task to tackle is to find a person or form 
a team going after this. The number of downloads would help a lot to focus on 
important packages. Maintainers could also be advised to check whether the 
upstream representation of MacPorts in the installation section of macOS 
compares to homebrew.

After being directed to the MacPorts homepage, it does not stop. The next step 
is searching on the pages for MacPorts for ImageMagick. This gets you to the 
page: "https://ports.macports.org/port/ImageMagick/summary“, which still does 
not tell you 'port install imagemagick'. One would guess that 'Build 
Information' gives you a hint and click on it, but no. Don’t get me wrong, for 
me as an experienced user of MacPorts this page is very helpful and tells me, 
what i want to know about a package, but for less experienced users it makes 
MacPorts look overly complicated. I suggest to make following changes to this 
page:

1) Place the 'View on Github' Button next to the name

2) Put the command 'port install PACKAFE_NAME' to a prominent position.

3) Change the sequence of the fields according to the importance for users, in 
particular first time users. 

My suggestion is this sequence.

1) Version
2) Variants
3) Platform
4) Categories
5) Depends on
6) Dependency of
7) Homepage
8) License
9) Maintainer

I also think that the concept of variants needs more explanations. Clicking on 
the variants does not give any indications about the implications of a variant. 
There is also no hint, which variant I should choose as a first time user. 
Hints regarding a default variant and hints about binary installation would be 
helpful. I am not sure about it, but it might be better to defer this 
information to another subpage, because of secondary importance.

I hope, i did not hurt or offend anyone. The work done by all the people for 
MacPorts is amazing and it is important to keep up the spirit. MacPorts has a 
rock solid foundation and only its appearance needs some corrections.

Regards - Michael.

Re: FAQ wording (was: Re: Desolate Condition)

[Jason Liu]

>
> What if the end of the first sentence was changed to: "ports will be
> installed for only the architecture you're currently running on."?
>

Besides being the most concisely worded, I also find this version to be the
most unambiguous. I think leaving the words "build/built" and "compile" out
of the sentence entirely would be for the best.

-- 
Jason Liu


On Mon, Apr 5, 2021 at 10:15 AM wowfunha...@gmail.com 
wrote:

> > It's a tricky thing to state both concisely and accurately because the
> > compilation may indeed happen on the user's computer after installation
> > is requested. Or it may not. The ambiguity of whether "be compiled" is a
> > verb in the passive voice ("the code is being compiled") or a
> > description of a state ("this is code compiled for x86_64") may reflect
> > the author's awareness of the undecidedness of which one will actually
> > happen.
> >
> > Improvements to the text's clarity are very welcome, of course.
> >
> > - Josh
>
> What if the end of the first sentence was changed to: "ports will be
> installed for only the architecture you're currently running on."?
> Basically mirroring the other change made on Saturday.
>
>
>

Re: FAQ wording (was: Re: Desolate Condition)

[wowfunha...@gmail.com]

> It's a tricky thing to state both concisely and accurately because the 
> compilation may indeed happen on the user's computer after installation 
> is requested. Or it may not. The ambiguity of whether "be compiled" is a 
> verb in the passive voice ("the code is being compiled") or a 
> description of a state ("this is code compiled for x86_64") may reflect 
> the author's awareness of the undecidedness of which one will actually 
> happen.
> 
> Improvements to the text's clarity are very welcome, of course.
> 
> - Josh

What if the end of the first sentence was changed to: "ports will be installed 
for only the architecture you're currently running on."? Basically mirroring 
the other change made on Saturday.

FAQ wording (was: Re: Desolate Condition)

[Joshua Root]

On 2021-4-4 11:20 , Kevin Reid wrote:
On Sat, Apr 3, 2021 at 5:22 PM wowfunha...@gmail.com 
 > wrote:


I know it's just one data point, but I thought the replies I got on
this Hacker News comment today were interesting. I can understand
why he/she got confused, and I wonder if there's anything MacPorts
could do to make it clearer.
https://news.ycombinator.com/item?id=26678498



As worded, the FAQ text "the ports you install will be compiled only for 
the architecture you're currently running on" implies (in the linguistic 
rather than logical sense) that the compilation happens after you 
request installation. The minimal patch would be to change the tense to 
"will *have been* compiled only for", but an even better rewording might 
be something like


"…the ports' installed binaries will have been compiled for your
computer's architecture…"


to avoid putting the user's computer in any active role in that sentence 
and to make it clear we're talking about the binaries and not the 
compilation process per se. Perhaps "will contain machine code for" 
would be even more rigorous, but it might be less familiar.


Of course, this sentence may not be the whole problem, but it's what I 
saw in that thread, it's likely /part/ of the problem, and it made a 
good example of the kind of sentence that can be read differently by a 
reader not already familiar with the subjet.


It's a tricky thing to state both concisely and accurately because the 
compilation may indeed happen on the user's computer after installation 
is requested. Or it may not. The ambiguity of whether "be compiled" is a 
verb in the passive voice ("the code is being compiled") or a 
description of a state ("this is code compiled for x86_64") may reflect 
the author's awareness of the undecidedness of which one will actually 
happen.


Improvements to the text's clarity are very welcome, of course.

- Josh

Re: Desolate Condition

[Kevin Reid]

On Sat, Apr 3, 2021 at 5:22 PM wowfunha...@gmail.com 
wrote:

> I know it's just one data point, but I thought the replies I got on this
> Hacker News comment today were interesting. I can understand why he/she got
> confused, and I wonder if there's anything MacPorts could do to make it
> clearer. https://news.ycombinator.com/item?id=26678498
>

As worded, the FAQ text "the ports you install will be compiled only for
the architecture you're currently running on" implies (in the linguistic
rather than logical sense) that the compilation happens after you request
installation. The minimal patch would be to change the tense to "will *have
been* compiled only for", but an even better rewording might be something
like

"…the ports' installed binaries will have been compiled for your computer's
architecture…"


to avoid putting the user's computer in any active role in that sentence
and to make it clear we're talking about the binaries and not the
compilation process per se. Perhaps "will contain machine code for" would
be even more rigorous, but it might be less familiar.

Of course, this sentence may not be the whole problem, but it's what I saw
in that thread, it's likely *part* of the problem, and it made a good
example of the kind of sentence that can be read differently by a reader
not already familiar with the subjet.

Re: Desolate Condition

[Joshua Root]

On 2021-4-4 18:29 , Ruben Di Battista wrote:
Since now we're starting to have stats collected, it might be maybe 
worth it to provide binaries instead of standard variants, more for the 
most requested ones?


Indeed, one of the goals of the stats is to help figure out when the 
default variants for ports should be changed. Building a handful of 
different variant sets for some ports rather than just one would also be 
nice, but requires a bit more work on the buildbot side. We could also 
use some tools to help analyse the mpstats data to detect such situations.


- Josh

Re: Desolate Condition

[Ruben Di Battista]

Since now we're starting to have stats collected, it might be maybe worth
it to provide binaries instead of standard variants, more for the most
requested ones?

On Sun, 4 Apr 2021, 04:07 Joshua Root,  wrote:

> On 2021-4-4 11:35 , Craig Treleaven wrote:
> >> On Apr 3, 2021, at 8:21 PM, wowfunha...@gmail.com
> >>   >> > wrote:
> >>
> >> I see this misconception /all over the place/, that Homebrew is fast
> >> because it uses prebuilt binaries, whereas MacPorts makes you wait
> >> while software is compiled. It can't /just/ be due to outdated
> >> information, if we're more than a decade out from when the buildbot
> >> went live.
> >>
> >> I know it's just one data point, but I thought the replies I got on
> >> this Hacker News comment today were interesting. I can understand why
> >> he/she got confused, and I wonder if there's anything MacPorts could
> >> do to make it clearer. https://news.ycombinator.com/item?id=26678498
> >> 
> >
> > It happens that I just did a self update and upgraded 20 ports on 10.15.
> >   6 or the 20 were built from source.  I believe this is higher than
> > usual due to the backlog on the 10.15 builbot.  Even in the best case,
> > however, a fair number of ports will be built from source for the
> > well-known reasons.  It would be interesting to know, say, how many of
> > our most-requested ports are always built from source.
> >
> >
> https://ports.macports.org/statistics/ports/?days=30=-req_count=-total_count=port
> > <
> https://ports.macports.org/statistics/ports/?days=30=-req_count=-total_count=port
> >
> >
> > Eg, git is our second-most requested port and it is always built from
> > source AFAIK.
> >
> > Almost any reasonably complex package will have some of its dependencies
> > that must be built from source.
> >
> > To the average user, I would suggest that we should emphasize that
> > MacPorts installs binaries whenever allowed by licensing but makes a
> > serious effort to avoid contravening the various open source licenses.
> >   Plus MacPorts offers many more options (“variants”) to customize
> > installations and offers a wide breadth of packages.
>
> I wrote a new FAQ and slightly reworded the one about universal
> binaries. The latter was originally written before the buildbot existed,
> so it was saying "build" where "install" is now more accurate. However
> +universal is still a non-default variant and so very often won't be
> available as a binary.
>
> - Josh
>

Re: Desolate Condition

[Joshua Root]

On 2021-4-4 11:35 , Craig Treleaven wrote:
On Apr 3, 2021, at 8:21 PM, wowfunha...@gmail.com 
 > wrote:


I see this misconception /all over the place/, that Homebrew is fast 
because it uses prebuilt binaries, whereas MacPorts makes you wait 
while software is compiled. It can't /just/ be due to outdated 
information, if we're more than a decade out from when the buildbot 
went live.


I know it's just one data point, but I thought the replies I got on 
this Hacker News comment today were interesting. I can understand why 
he/she got confused, and I wonder if there's anything MacPorts could 
do to make it clearer. https://news.ycombinator.com/item?id=26678498 



It happens that I just did a self update and upgraded 20 ports on 10.15. 
  6 or the 20 were built from source.  I believe this is higher than 
usual due to the backlog on the 10.15 builbot.  Even in the best case, 
however, a fair number of ports will be built from source for the 
well-known reasons.  It would be interesting to know, say, how many of 
our most-requested ports are always built from source.


https://ports.macports.org/statistics/ports/?days=30=-req_count=-total_count=port 



Eg, git is our second-most requested port and it is always built from 
source AFAIK.


Almost any reasonably complex package will have some of its dependencies 
that must be built from source.


To the average user, I would suggest that we should emphasize that 
MacPorts installs binaries whenever allowed by licensing but makes a 
serious effort to avoid contravening the various open source licenses. 
  Plus MacPorts offers many more options (“variants”) to customize 
installations and offers a wide breadth of packages.


I wrote a new FAQ and slightly reworded the one about universal 
binaries. The latter was originally written before the buildbot existed, 
so it was saying "build" where "install" is now more accurate. However 
+universal is still a non-default variant and so very often won't be 
available as a binary.


- Josh

Re: Desolate Condition

[Craig Treleaven]

> On Apr 3, 2021, at 8:21 PM, wowfunha...@gmail.com  
> wrote:
> 
>>> On 2021-1-27 02:57 , Andrew Janke wrote:
>>> I didn't know that! I must be behind the times with the state of  MacPorts. 
>>> Thanks for the update.
>> About a decade behind -- the buildbot went live in 2011. ;)
>> - Josh
> 
> I see this misconception all over the place, that Homebrew is fast because it 
> uses prebuilt binaries, whereas MacPorts makes you wait while software is 
> compiled. It can't just be due to outdated information, if we're more than a 
> decade out from when the buildbot went live.
> 
> I know it's just one data point, but I thought the replies I got on this 
> Hacker News comment today were interesting. I can understand why he/she got 
> confused, and I wonder if there's anything MacPorts could do to make it 
> clearer. https://news.ycombinator.com/item?id=26678498 
> 
It happens that I just did a self update and upgraded 20 ports on 10.15.  6 or 
the 20 were built from source.  I believe this is higher than usual due to the 
backlog on the 10.15 builbot.  Even in the best case, however, a fair number of 
ports will be built from source for the well-known reasons.  It would be 
interesting to know, say, how many of our most-requested ports are always built 
from source.

https://ports.macports.org/statistics/ports/?days=30=-req_count=-total_count=port

Eg, git is our second-most requested port and it is always built from source 
AFAIK.

Almost any reasonably complex package will have some of its dependencies that 
must be built from source.  

To the average user, I would suggest that we should emphasize that MacPorts 
installs binaries whenever allowed by licensing but makes a serious effort to 
avoid contravening the various open source licenses.  Plus MacPorts offers many 
more options (“variants”) to customize installations and offers a wide breadth 
of packages.

Craig

Re: Desolate Condition

[wowfunha...@gmail.com]

>> On 2021-1-27 02:57 , Andrew Janke wrote:
>> I didn't know that! I must be behind the times with the state of  MacPorts. 
>> Thanks for the update.
> About a decade behind -- the buildbot went live in 2011. ;)
> - Josh

I see this misconception all over the place, that Homebrew is fast because it 
uses prebuilt binaries, whereas MacPorts makes you wait while software is 
compiled. It can't just be due to outdated information, if we're more than a 
decade out from when the buildbot went live.

I know it's just one data point, but I thought the replies I got on this Hacker 
News comment today were interesting. I can understand why he/she got confused, 
and I wonder if there's anything MacPorts could do to make it clearer. 
https://news.ycombinator.com/item?id=26678498

Re: Desolate Condition

[Ryan Schmidt]

On Jan 31, 2021, at 11:05, harens wrote:

> I completely agree that Homebrew is currently winning at publicity.

What should the MacPorts community be doing do publicize MacPorts better?


> I think vocalising the points of Saagar Jha’s article Thoughts on macOS 
> Package Managers would be very helpful, since there’s a lot going in 
> MacPorts’ favour:
> 
>   • MacPorts is much better from a security point of view (considering 
> the whole /usr/local/issue)
>   • Package availability is much higher, especially for older packages
>   • There’s support for much older macOS versions
>   • Being the “pro” tool, there’s a lot more options and functionality
>   • We don’t send user’s data off as analytics without their permission
>   • Their community is in shambles after each controversial decision 
> (e.g. Google Analytics, resignation of members)
>   • etc. etc.

These are good points, and I would not be opposed to a redesign of the MacPorts 
web site to modernize, remove cruft, highlight what we do well. However I would 
avoid referring to our competition by name on our web site or pointing out 
things that we think they do poorly. There have already been a couple efforts 
in the past years to create new MacPorts web sites; they deserve further 
consideration.


> We also need to make it easier for users to contribute. About a year ago, I 
> didn’t really know about MacPorts and solely used Homebrew. After I started 
> contributing, I realised how much better MacPorts is, and I’m sure many other 
> new contributors will feel the same.
> 
> I’ve tried to improve the situation with tools like seaport, but to compete 
> with Homebrew’s golden standard brew bump-formula-pr and the Homebrew bump 
> GitHub Action, which allows users to easily contribute without knowing any 
> git, will require some work.

We did already make it easier to contribute by moving to GitHub in late 2016. 
Moving was difficult, we had resisted it for many years, and it helped that in 
2016 Apple paid me to do the move, but even with that incentive, I admit I 
wasn't convinced that moving to GitHub would improve contributions. But happily 
it has. I underestimated how many users were familiar with git and wished to 
contribute by sending pull requests.

Certainly we also still accept contributions from users who are not familiar 
with git, as we did before we moved to GitHub. Users can continue to submit 
patches as an attachment to a Trac ticket. Or users could use the GitHub web 
interface to make a fork and edit a file, all without needing to know how to 
use git.

I am not familiar with seaport, bump-formula-pr, or Homebrew bump GitHub 
Action. You could describe them if you like. But I do want to caution against 
the creation and use of tools that automate updating a port. I recall a batch 
of PRs some time ago from someone who had clearly just updated the version and 
checksums of a bunch of ports without ever testing that they built; most of 
them failed to build in our CI system. Updating version and checksums is all 
that's needed in the *ideal* case but there are far too many occasions when 
that is insufficient to be able to recommend relying on an automated tool that 
only does those things. If updating a port automatically were possible, we'd do 
it. It's not; it requires human analysis and thought; that's the job of port 
maintainers.

This hasn't stopped many developers including myself [1] from developing such 
tools, but they should be used as a first step, not as an only step.

[1] 
https://github.com/ryandesign/macports-user-ryandesign/blob/master/scripts/portcheckup

Re: Desolate Condition

[Jason Liu]

When popular software titles either get added as new ports, or when they
get a version update, maybe there should be some sort of post. For example,
I believe that LibreOffice recently got added to the ports tree, although
I'm not sure how complete of a package it is compared to the DMG installer
that is available directly from libreoffice.org; it's possible that it
might still be a work-in-progress. However, whenever one of the popular
titles reaches parity with the upstream authors' DMG installer, then we
could post something along the lines of " is now available
as an official package in MacPorts!"

I realize that what is considered a "popular software title" is very
subjective. Maybe "high visibility title" might be a more appropriate
phrase? I'm not sure. But anyway, that's my suggestion.

-- 
Jason Liu


On Sat, Jan 30, 2021 at 12:50 PM Christopher Nielsen <
masc...@rochester.rr.com> wrote:

> *On 2021-01-30-S, at 12:00, Rainer Müller  > wrote:*
>
>
> Yes, we do have a Twitter account [1], but we are not using it much.
> Mostly we announce new releases and maintenance stuff there.
>
> I added a new SocialMedia wiki page [2] to document the existence of such
> social media presence. This also has the list of users that already have
> access and the signatures they use for tweets.
>
> Help with this would be very welcome! I can give out access to more users
> via TweetDeck [3], if you tell me your Twitter handle.
>
> Rainer
>
> [1] https://twitter.com/macports
> [2] https://trac.macports.org/wiki/SocialMedia
> [3] https://tweetdeck.twitter.com
>
>
> You’re welcome to add me. My Twitter handle is @ChrisNielsen333.
>
> In terms of current tweet-worthy items, there are at least two that I’d
> suggest:
> * The recent migration to libjpeg-turbo. It was quick, painless, and a big
> win for our users!
> * All of the great work folks have been doing, to support Apple’s M1 Macs.
>
> Anything else?
>

Re: Desolate Condition

[harens]

I completely agree that Homebrew is currently winning at publicity.

I think vocalising the points of Saagar Jha’s article Thoughts on macOS Package 
Managers 
 
would be very helpful, since there’s a lot going in MacPorts’ favour:

MacPorts is much better from a security point of view (considering the whole 
/usr/local/issue)
Package availability is much higher, especially for older packages
There’s support for much older macOS versions
Being the “pro” tool, there’s a lot more options and functionality
We don’t send user’s data off as analytics without their permission
Their community is in shambles after each controversial decision (e.g. Google 
Analytics , resignation of members 
)
etc. etc.

We also need to make it easier for users to contribute. About a year ago, I 
didn’t really know about MacPorts and solely used Homebrew. After I started 
contributing, I realised how much better MacPorts is, and I’m sure many other 
new contributors will feel the same.

I’ve tried to improve the situation with tools like seaport 
, but to compete with Homebrew’s golden 
standard brew bump-formula-pr 

 and the Homebrew bump GitHub Action 
, which allows 
users to easily contribute without knowing any git, will require some work.

Haren.

Re: Desolate Condition

[Christopher Nielsen]

On 2021-01-30-S, at 12:00, Rainer Müller  wrote:
> 
> Yes, we do have a Twitter account [1], but we are not using it much. Mostly 
> we announce new releases and maintenance stuff there.
> 
> I added a new SocialMedia wiki page [2] to document the existence of such 
> social media presence. This also has the list of users that already have 
> access and the signatures they use for tweets.
> 
> Help with this would be very welcome! I can give out access to more users via 
> TweetDeck [3], if you tell me your Twitter handle.
> 
> Rainer
> 
> [1] https://twitter.com/macports
> [2] https://trac.macports.org/wiki/SocialMedia
> [3] https://tweetdeck.twitter.com

You’re welcome to add me. My Twitter handle is @ChrisNielsen333.

In terms of current tweet-worthy items, there are at least two that I’d suggest:
* The recent migration to libjpeg-turbo. It was quick, painless, and a big win 
for our users!
* All of the great work folks have been doing, to support Apple’s M1 Macs.

Anything else?

Re: Desolate Condition

[Rainer Müller]

On 26/01/2021 16.12, Christopher Nielsen wrote:
> One advantage that HomeBrew does have, though, is cachet: There are so many
> times when articles - or even organizations, such as Google - simply recommend
> using HomeBrew… with no mention of MacPorts.
> 
> So, my feeling is that we need to up our public relations game. Do we have an
> active social media presence, for example? (Twitter in particular?)>
> Of note, while I’m not an expert in social media relations, I’d happily
> volunteer to help with it.

Yes, we do have a Twitter account [1], but we are not using it much. Mostly we
announce new releases and maintenance stuff there.

I added a new SocialMedia wiki page [2] to document the existence of such social
media presence. This also has the list of users that already have access and the
signatures they use for tweets.

Help with this would be very welcome! I can give out access to more users via
TweetDeck [3], if you tell me your Twitter handle.

Rainer

[1] https://twitter.com/macports
[2] https://trac.macports.org/wiki/SocialMedia
[3] https://tweetdeck.twitter.com

Re: Desolate Condition

[Ken Cunningham]

> Possibly relevant: I'm co-maintainer of Octave.app, a "native" Mac app 
> distribution of GNU Octave (https://octave-app.org/). It's currently built on 
> top of Homebrew.

MacPorts already creates a nice Octave.app now, fyi. If you installed MP into a 
custom prefix (/opt/octave, say) you could make an installer with almost zero 
further effort.

I have the current Octave working nicely all the way back to Tiger PPC. How's 
that for MacPorts' older systems support!

If you want a self-contained app bundle you would look at dylibbundler, or use 
your own script.

Tenfourfox is a browser for older systems based on FireFox, written using 
MacPorts tools and some custom parts, and bundled with a custom script.
Homebrew's current wine offerings are written with and bundled using MacPorts, 
and installed using homebrew's cask feature. (which kinda sucks as we don't 
have it in MacPorts, but that's another story).
Ken

Re: Desolate Condition

[Andrew Janke]

On 1/26/21 9:41 PM, Craig Treleaven wrote:
> I have used MacPorts to package a substantial application (MythTV).  As an 
> overview, MythTV and all its dependencies were installed to a custom prefix 
> (/opt/dvr)*.  A couple of helper apps (Applescripts, if you want the full 
> truth) are the only things installed under /Applications/MacPorts/MythTV.  
> The package installer recreates this layout on the destination machine.  I 
> don’t see why you couldn’t continue with your current layout, however.
>
> MacPorts provides support to create a standard package installer (port mpkg) 
> or dmg (port mdmg).  See man port-mpkg for the basics.  If it helps, I wrote 
> a wiki page with a few of the issues that I encountered:
>
> https://trac.macports.org/wiki/howto/CreateInstallers

Cool, thanks! I think this will be helpful.

> Ping me if you have questions.
>
> Craig
> * In a custom prefix, _everything_ has to be built from source.  The initial 
> build will take a _long_ time.  A very long time.

Ohh, I'm used to that. As a packager I'm okay with eating that build time.

Cheers,
Andrew

Re: Desolate Condition

[Craig Treleaven]

> On Jan 26, 2021, at 9:13 PM, Andrew Janke  wrote:
> 
> Possibly relevant: I'm co-maintainer of Octave.app, a "native" Mac app
> distribution of GNU Octave (https://octave-app.org/). It's currently
> built on top of Homebrew.
> 
> I'm tentatively planning on migrating Octave.app to be built on top of
> MacPorts in the near future. Partially because I think MacPorts is a
> more stable, configurable, "pro" tool more suitable to building
> redistributable apps (which is explicitly not supported by Homebrew),
> but mostly because I refuse to upgrade from macOS 10.14 (because I'm an
> Aperture user) and Homebrew's going to drop support for 10.14.
> 
> The way this thing works is that I set up a whole Homebrew installation
> under a custom prefix at "/Applications/Octave-.app" and then
> wrap that up as an app bundle.
> 
> Do y'all have any advice for me?
> 
> If this transition happens, a "Powered by MacPorts!" banner goes on the
> bottom of our website. I have absolutely no clue how many users we have,
> but I know that at least a couple hundred European college students
> along with some scientists in the US are using it.

I have used MacPorts to package a substantial application (MythTV).  As an 
overview, MythTV and all its dependencies were installed to a custom prefix 
(/opt/dvr)*.  A couple of helper apps (Applescripts, if you want the full 
truth) are the only things installed under /Applications/MacPorts/MythTV.  The 
package installer recreates this layout on the destination machine.  I don’t 
see why you couldn’t continue with your current layout, however.

MacPorts provides support to create a standard package installer (port mpkg) or 
dmg (port mdmg).  See man port-mpkg for the basics.  If it helps, I wrote a 
wiki page with a few of the issues that I encountered:

https://trac.macports.org/wiki/howto/CreateInstallers

Ping me if you have questions.

Craig
* In a custom prefix, _everything_ has to be built from source.  The initial 
build will take a _long_ time.  A very long time.

Re: Desolate Condition

[Andrew Janke]

On 1/26/21 3:50 PM, Nils Breunese wrote:
> Christopher Nielsen  wrote:
>
>> One advantage that HomeBrew does have, though, is cachet: There are so many 
>> times when articles - or even organizations, such as Google - simply 
>> recommend using HomeBrew… with no mention of MacPorts.
> I think it’s a great idea to always send pull requests to update upstream 
> docs and readme files with installation instructions for MacPorts when you 
> start maintaining a port. So, to all maintainers: take a look at the ports 
> you maintain and whether the upstream docs and readme have installation 
> instructions for MacPorts.
>
> Nils.

Possibly relevant: I'm co-maintainer of Octave.app, a "native" Mac app
distribution of GNU Octave (https://octave-app.org/). It's currently
built on top of Homebrew.

I'm tentatively planning on migrating Octave.app to be built on top of
MacPorts in the near future. Partially because I think MacPorts is a
more stable, configurable, "pro" tool more suitable to building
redistributable apps (which is explicitly not supported by Homebrew),
but mostly because I refuse to upgrade from macOS 10.14 (because I'm an
Aperture user) and Homebrew's going to drop support for 10.14.

The way this thing works is that I set up a whole Homebrew installation
under a custom prefix at "/Applications/Octave-.app" and then
wrap that up as an app bundle.

Do y'all have any advice for me?

If this transition happens, a "Powered by MacPorts!" banner goes on the
bottom of our website. I have absolutely no clue how many users we have,
but I know that at least a couple hundred European college students
along with some scientists in the US are using it.

Cheers,
Andrew

Re: Desolate Condition

[Eric Borisch]

FWIW (on FreeBSD; apologies for semi-off-topic; I won't continue any
further discussion on-list):

If you want more frequent pkg updates, create the file
/usr/local/etc/pkg/repos/FreeBSD.conf with contents:

FreeBSD: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest;
}

This will switch you (with a 'pkg update -f') from "quarterly" to
"latest". See also: https://wiki.freebsd.org/Ports/QuarterlyBranch for
rationale behind each.

I also find ports-mgmt/synth to be fantastic for maintaining a mix of
pre-built (downloaded compiled) and customized (non-standard-option)
packages. This is similar to how MacPorts will download (as permitted)
pre-compiled ports with standard variants, but build locally for
non-standard variants.

  - Eric


On Tue, Jan 26, 2021 at 9:55 AM Marius Schamschula
 wrote:
>
> Andrew,
>
> MacPorts provides pre-built packages for more macOS versions than Homebrew.
>
> However, MacPorts is very careful not to provide packages where the upstream 
> license prohibits us from doing so.
>
> Other pre-built packages are not provided if they depend on said packages to 
> be build by our buildbots.
>
> Installing on my Mac using MacPorts is much faster than on my servers under 
> FreeBSD where everything literally has to be build locally, as pre-built 
> packages may be up three months out of date.
>
> On Jan 26, 2021, at 9:40 AM, Andrew Janke  wrote:
>
>
>
> On 1/26/21 10:12 AM, Christopher Nielsen wrote:
>
> Ken Cunningham wrote:
>
> homebrew is in shambles.
>
> their long-touted "no-sudo" and "no PATH" advantage from installing into 
> /usr/local has been eliminated by Apple as the horrible security threat it 
> always was. They have to retool into /opt/homebrew and make 10,000 builds 
> respect the build args now.
>
> They stripped out all their universal handling code a few years ago, can't 
> put it back, and so can't do the critical universal builds any more. They 
> tell everyone universal is wasteful, lipo things manually, and run the x86_64 
> homebrew on Apple Silicon.
>
> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the place to 
> be.
>
>
> Personnally, I’ve never actually tried HomeBrew, as I didn’t want anything 
> installed into core OS areas. And after choosing  MacPorts years ago - 10+ at 
> this point? - I’ve always been very happy with the experience. Enough so that 
> I’m finally giving back, as a contributor!
>
> One advantage that HomeBrew does have, though, is cachet: There are so many 
> times when articles - or even organizations, such as Google - simply 
> recommend using HomeBrew… with no mention of MacPorts.
>
> So, my feeling is that we need to up our public relations game. Do we have an 
> active social media presence, for example? (Twitter in particular?)
>
> Of note, while I’m not an expert in social media relations, I’d happily 
> volunteer to help with it.
>
> Thoughts?
>
>
> Hi! Long-time user of both Homebrew and MacPorts here; former Homebrew 
> maintainer.
>
> It's definitely a PR issue; Homebrew is winning on that front.
>
> IMHO, the other thing is that Homebrew is fun to use and accessible to 
> less-technical users. Friendlier command output, low-jargon documentation, 
> sense of humor, fun emojis. MacPorts feels like more of a "pro" thing and 
> serious sysadmin tool, and its command output can be kind of technical and 
> intimidating. I think the Homebrew approach is attractive to a lot of general 
> Mac users, especially those approaching a package manager for the first time.
>
> Another big thing is that Homebrew ships binaries for everything, so you can 
> do a full Homebrew install of a big toolchain in just a few minutes, where it 
> might take hours to compile. MacPorts still builds everything from source, 
> right?
>
> Those are the reasons I always recommend Homebrew to new Mac package manager 
> users, even though I think both are good tools.
>
> Cheers,
> Andrew
>
>

Re: Desolate Condition

[Nils Breunese]

Christopher Nielsen  wrote:

> One advantage that HomeBrew does have, though, is cachet: There are so many 
> times when articles - or even organizations, such as Google - simply 
> recommend using HomeBrew… with no mention of MacPorts.

I think it’s a great idea to always send pull requests to update upstream docs 
and readme files with installation instructions for MacPorts when you start 
maintaining a port. So, to all maintainers: take a look at the ports you 
maintain and whether the upstream docs and readme have installation 
instructions for MacPorts.

Nils.

Re: Desolate Condition

[Jason Liu]

>
> One advantage that HomeBrew does have, though, is cachet: There are so
> many times when articles - or even organizations, such as Google - simply
> recommend using HomeBrew… with no mention of MacPorts.
>
> So, my feeling is that we need to up our public relations game. Do we have
> an active social media presence, for example? (Twitter in particular?)
>
> Of note, while I’m not an expert in social media relations, I’d happily
> volunteer to help with it.
>
> Thoughts?
>

I completely agree with this point. Due to MacPorts' low social media
visibility, and thus low mind share in this day and age, it seems that lots
of people, even including software authors, don't seem to consider MacPorts
as a viable (or at the very least, a mainstream) method of obtaining
software. I see plenty of open source projects have a blurb on their
websites saying " is available through Homebrew using 'brew
install --cask '", but I never see an equivalent blurb for
MacPorts these days.

I also agree with Andrew Janke's point that "MacPorts feels like more of a
"pro" thing and serious sysadmin tool, and its command output can be kind
of technical and intimidating." MacPorts essentially adds a *nix-style
package management system onto a Mac, and these *nix PMSes are also
(in)famous for feeling technical and intimidating. Perhaps a GUI like
Pallet would help in this regard? There seems to be much higher comfort
levels with GUI-based "app stores", even among non-technical users.

-- 
Jason Liu


On Tue, Jan 26, 2021 at 10:12 AM Christopher Nielsen <
masc...@rochester.rr.com> wrote:

>
> *Ken Cunningham wrote:*
> homebrew is in shambles.
>
> their long-touted "no-sudo" and "no PATH" advantage from installing into
> /usr/local has been eliminated by Apple as the horrible security threat it
> always was. They have to retool into /opt/homebrew and make 10,000 builds
> respect the build args now.
>
> They stripped out all their universal handling code a few years ago, can't
> put it back, and so can't do the critical universal builds any more. They
> tell everyone universal is wasteful, lipo things manually, and run the
> x86_64 homebrew on Apple Silicon.
>
> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the place
> to be.
>
>
> Personnally, I’ve never actually tried HomeBrew, as I didn’t want anything
> installed into core OS areas. And after choosing  MacPorts years ago - 10+
> at this point? - I’ve always been very happy with the experience. Enough so
> that I’m finally giving back, as a contributor!
>
> One advantage that HomeBrew does have, though, is cachet: There are so
> many times when articles - or even organizations, such as Google - simply
> recommend using HomeBrew… with no mention of MacPorts.
>
> So, my feeling is that we need to up our public relations game. Do we have
> an active social media presence, for example? (Twitter in particular?)
>
> Of note, while I’m not an expert in social media relations, I’d happily
> volunteer to help with it.
>
> Thoughts?
>

Re: Desolate Condition

[Joshua Root]

On 2021-1-27 02:57 , Andrew Janke wrote:
I didn't know that! I must be behind the times with the state of 
MacPorts. Thanks for the update.


About a decade behind -- the buildbot went live in 2011. ;)

- Josh

Re: Desolate Condition

[Andrew Janke]

I didn't know that! I must be behind the times with the state of
MacPorts. Thanks for the update.

Cheers,
Andrew

On 1/26/21 10:54 AM, Marius Schamschula wrote:
> Andrew,
>
> MacPorts provides pre-built packages for more macOS versions than
> Homebrew.
>
> However, MacPorts is very careful not to provide packages where the
> upstream license prohibits us from doing so.
>
> Other pre-built packages are not provided if they depend on said
> packages to be build by our buildbots.
>
> Installing on my Mac using MacPorts is much faster than on my servers
> under FreeBSD where everything literally has to be build locally, as
> pre-built packages may be up three months out of date.
>
>> On Jan 26, 2021, at 9:40 AM, Andrew Janke > > wrote:
>>
>>
>>
>> On 1/26/21 10:12 AM, Christopher Nielsen wrote:
 /Ken Cunningham wrote:
 /
 homebrew is in shambles.

 their long-touted "no-sudo" and "no PATH" advantage from installing
 into /usr/local has been eliminated by Apple as the horrible
 security threat it always was. They have to retool into
 /opt/homebrew and make 10,000 builds respect the build args now.

 They stripped out all their universal handling code a few years
 ago, can't put it back, and so can't do the critical universal
 builds any more. They tell everyone universal is wasteful, lipo
 things manually, and run the x86_64 homebrew on Apple Silicon.

 So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the
 place to be.
>>>
>>> Personnally, I’ve never actually tried HomeBrew, as I didn’t want
>>> anything installed into core OS areas. And after choosing  MacPorts
>>> years ago - 10+ at this point? - I’ve always been very happy with
>>> the experience. Enough so that I’m finally giving back, as a
>>> contributor!
>>>
>>> One advantage that HomeBrew does have, though, is cachet: There are
>>> so many times when articles - or even organizations, such as Google
>>> - simply recommend using HomeBrew… with no mention of MacPorts.
>>>
>>> So, my feeling is that we need to up our public relations game. Do
>>> we have an active social media presence, for example? (Twitter in
>>> particular?)
>>>
>>> Of note, while I’m not an expert in social media relations, I’d
>>> happily volunteer to help with it.
>>>
>>> Thoughts?
>>
>> Hi! Long-time user of both Homebrew and MacPorts here; former
>> Homebrew maintainer.
>>
>> It's definitely a PR issue; Homebrew is winning on that front.
>>
>> IMHO, the other thing is that Homebrew is /fun/ to use and accessible
>> to less-technical users. Friendlier command output, low-jargon
>> documentation, sense of humor, fun emojis. MacPorts feels like more
>> of a "pro" thing and serious sysadmin tool, and its command output
>> can be kind of technical and intimidating. I think the Homebrew
>> approach is attractive to a lot of general Mac users, especially
>> those approaching a package manager for the first time.
>>
>> Another big thing is that Homebrew ships binaries for everything, so
>> you can do a full Homebrew install of a big toolchain in just a few
>> minutes, where it might take hours to compile. MacPorts still builds
>> everything from source, right?
>>
>> Those are the reasons I always recommend Homebrew to new Mac package
>> manager users, even though I think both are good tools.
>>
>> Cheers,
>> Andrew
>

Re: Desolate Condition

[Marius Schamschula]

Andrew,

MacPorts provides pre-built packages for more macOS versions than Homebrew.

However, MacPorts is very careful not to provide packages where the upstream 
license prohibits us from doing so.

Other pre-built packages are not provided if they depend on said packages to be 
build by our buildbots.

Installing on my Mac using MacPorts is much faster than on my servers under 
FreeBSD where everything literally has to be build locally, as pre-built 
packages may be up three months out of date.

> On Jan 26, 2021, at 9:40 AM, Andrew Janke  wrote:
> 
> 
> 
> On 1/26/21 10:12 AM, Christopher Nielsen wrote:
>>> Ken Cunningham wrote:
>>> 
>>> homebrew is in shambles.
>>> 
>>> their long-touted "no-sudo" and "no PATH" advantage from installing into 
>>> /usr/local has been eliminated by Apple as the horrible security threat it 
>>> always was. They have to retool into /opt/homebrew and make 10,000 builds 
>>> respect the build args now.
>>> 
>>> They stripped out all their universal handling code a few years ago, can't 
>>> put it back, and so can't do the critical universal builds any more. They 
>>> tell everyone universal is wasteful, lipo things manually, and run the 
>>> x86_64 homebrew on Apple Silicon.
>>> 
>>> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the place to 
>>> be.
>> 
>> Personnally, I’ve never actually tried HomeBrew, as I didn’t want anything 
>> installed into core OS areas. And after choosing  MacPorts years ago - 10+ 
>> at this point? - I’ve always been very happy with the experience. Enough so 
>> that I’m finally giving back, as a contributor!
>> 
>> One advantage that HomeBrew does have, though, is cachet: There are so many 
>> times when articles - or even organizations, such as Google - simply 
>> recommend using HomeBrew… with no mention of MacPorts.
>> 
>> So, my feeling is that we need to up our public relations game. Do we have 
>> an active social media presence, for example? (Twitter in particular?)
>> 
>> Of note, while I’m not an expert in social media relations, I’d happily 
>> volunteer to help with it.
>> 
>> Thoughts?
> 
> Hi! Long-time user of both Homebrew and MacPorts here; former Homebrew 
> maintainer.
> 
> It's definitely a PR issue; Homebrew is winning on that front.
> 
> IMHO, the other thing is that Homebrew is fun to use and accessible to 
> less-technical users. Friendlier command output, low-jargon documentation, 
> sense of humor, fun emojis. MacPorts feels like more of a "pro" thing and 
> serious sysadmin tool, and its command output can be kind of technical and 
> intimidating. I think the Homebrew approach is attractive to a lot of general 
> Mac users, especially those approaching a package manager for the first time.
> 
> Another big thing is that Homebrew ships binaries for everything, so you can 
> do a full Homebrew install of a big toolchain in just a few minutes, where it 
> might take hours to compile. MacPorts still builds everything from source, 
> right?
> 
> Those are the reasons I always recommend Homebrew to new Mac package manager 
> users, even though I think both are good tools.
> 
> Cheers,
> Andrew

Re: Desolate Condition

[Andrew Janke]

On 1/26/21 10:12 AM, Christopher Nielsen wrote:
>> /Ken Cunningham wrote:
>> /
>> homebrew is in shambles.
>>
>> their long-touted "no-sudo" and "no PATH" advantage from installing
>> into /usr/local has been eliminated by Apple as the horrible security
>> threat it always was. They have to retool into /opt/homebrew and make
>> 10,000 builds respect the build args now.
>>
>> They stripped out all their universal handling code a few years ago,
>> can't put it back, and so can't do the critical universal builds any
>> more. They tell everyone universal is wasteful, lipo things manually,
>> and run the x86_64 homebrew on Apple Silicon.
>>
>> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the
>> place to be.
>
> Personnally, I’ve never actually tried HomeBrew, as I didn’t want
> anything installed into core OS areas. And after choosing  MacPorts
> years ago - 10+ at this point? - I’ve always been very happy with the
> experience. Enough so that I’m finally giving back, as a contributor!
>
> One advantage that HomeBrew does have, though, is cachet: There are so
> many times when articles - or even organizations, such as Google -
> simply recommend using HomeBrew… with no mention of MacPorts.
>
> So, my feeling is that we need to up our public relations game. Do we
> have an active social media presence, for example? (Twitter in
> particular?)
>
> Of note, while I’m not an expert in social media relations, I’d
> happily volunteer to help with it.
>
> Thoughts?

Hi! Long-time user of both Homebrew and MacPorts here; former Homebrew
maintainer.

It's definitely a PR issue; Homebrew is winning on that front.

IMHO, the other thing is that Homebrew is /fun/ to use and accessible to
less-technical users. Friendlier command output, low-jargon
documentation, sense of humor, fun emojis. MacPorts feels like more of a
"pro" thing and serious sysadmin tool, and its command output can be
kind of technical and intimidating. I think the Homebrew approach is
attractive to a lot of general Mac users, especially those approaching a
package manager for the first time.

Another big thing is that Homebrew ships binaries for everything, so you
can do a full Homebrew install of a big toolchain in just a few minutes,
where it might take hours to compile. MacPorts still builds everything
from source, right?

Those are the reasons I always recommend Homebrew to new Mac package
manager users, even though I think both are good tools.

Cheers,
Andrew

RE: Desolate Condition

[Christopher Nielsen]

> Ken Cunningham wrote:
> 
> homebrew is in shambles.
> 
> their long-touted "no-sudo" and "no PATH" advantage from installing into 
> /usr/local has been eliminated by Apple as the horrible security threat it 
> always was. They have to retool into /opt/homebrew and make 10,000 builds 
> respect the build args now.
> 
> They stripped out all their universal handling code a few years ago, can't 
> put it back, and so can't do the critical universal builds any more. They 
> tell everyone universal is wasteful, lipo things manually, and run the x86_64 
> homebrew on Apple Silicon.
> 
> So MacPorts, which works great from 10.4 PPC to 11.x arm64, is the place to 
> be.

Personnally, I’ve never actually tried HomeBrew, as I didn’t want anything 
installed into core OS areas. And after choosing  MacPorts years ago - 10+ at 
this point? - I’ve always been very happy with the experience. Enough so that 
I’m finally giving back, as a contributor!

One advantage that HomeBrew does have, though, is cachet: There are so many 
times when articles - or even organizations, such as Google - simply recommend 
using HomeBrew… with no mention of MacPorts.

So, my feeling is that we need to up our public relations game. Do we have an 
active social media presence, for example? (Twitter in particular?)

Of note, while I’m not an expert in social media relations, I’d happily 
volunteer to help with it.

Thoughts?