RE: Desolate Condition

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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?
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Marius Schamschula-3
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Joshua Root-8
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
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Jason Liu
In reply to this post by Christopher Nielsen
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 "<software_name> is available through Homebrew using 'brew install --cask <software_name>'", 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 <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Nils Breunese
In reply to this post by Christopher Nielsen
Christopher Nielsen <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Eric Borisch
In reply to this post by Marius Schamschula-3
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
<[hidden email]> 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 <[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Andrew Janke
In reply to this post by Nils Breunese


On 1/26/21 3:50 PM, Nils Breunese wrote:
> Christopher Nielsen <[hidden email]> 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-<version>.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

Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

pvr4me
> On Jan 26, 2021, at 9:13 PM, Andrew Janke <[hidden email]> 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-<version>.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.
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Ken Cunningham
In reply to this post by Christopher Nielsen
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



Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Rainer Müller-4
In reply to this post by Christopher Nielsen
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
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Christopher Nielsen
On 2021-01-30-S, at 12:00, Rainer Müller <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

harens
In reply to this post by Christopher Nielsen
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 Analyticsresignation 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.
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

Jason Liu
In reply to this post by Christopher Nielsen
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 "<software title> 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 <[hidden email]> wrote:
On 2021-01-30-S, at 12:00, Rainer Müller <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Desolate Condition

ryandesign2
Administrator
In reply to this post by harens


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