Re: Publicizing MacPorts

[Karl-Michael Schindler]

Hi

> Am 19.04.2021 um 16:47 schrieb Karl-Michael Schindler 
> :
> 
> I intend to do so, probably to a limited extend only. As a first step, I have 
> checked the upstream download pages of our top ten downloads. Less than 5 of 
> them mention macports properly. My next steps is to write to them. I also 
> want to extent the maintainer part of the docs with the direct to port 
> maintainer to check upstream download and install pages.
> 
> Michael.

Followup: 
At least, I managed to get MacPorts mentioned in the download or wiki pages of 
git and FFmpeg. At least my 2 cents to improve the visibility of macports, in 
particular there, where homebrew is already present. 

Michael.

Re: Publicizing MacPorts [installation]

[Marius Schamschula]

A script that’ll download the installer pkg and then run the installer cli 
command

i.e. something like

cd ~/Downloads
curl -OL /url/of/installer.pkg
sudo installer -pkg installer.pkg -target /


> On May 23, 2021, at 12:58 PM, Joshua Root  > wrote:
> 
> On 2021-5-23 20:40 , Artem Loenko via macports-dev wrote:
>> If you ask me, `curl | sh` is a better option than `sudo make install`.
>> Even if we compare them both as anti-patterns.
> 
> If you haven't done any verification of the integrity of what you're 
> installing, 'make install' is certainly also a bad idea. But at least you had 
> the opportunity to verify the gpg signature or whatever of the tarball you 
> downloaded before running that. (And sure, a lot of people don't, hence the 
> preference of the pkg installer for general use, which will refuse to install 
> if the signature can't be verified.)
> 
>> Plus, `make` requires a few dependencies. But when you install a package,
>> all the logic/doctor checks can be implemented on the `ports` binary level.
>> Install CLT, Xcode, check the environment, etc. Simple is better.
> 
> Sure.
> 
> - Josh



Marius
--
Marius Schamschula

Re: Publicizing MacPorts [installation]

[Joshua Root]

On 2021-5-23 20:40 , Artem Loenko via macports-dev wrote:

If you ask me, `curl | sh` is a better option than `sudo make install`.
Even if we compare them both as anti-patterns.


If you haven't done any verification of the integrity of what you're 
installing, 'make install' is certainly also a bad idea. But at least 
you had the opportunity to verify the gpg signature or whatever of the 
tarball you downloaded before running that. (And sure, a lot of people 
don't, hence the preference of the pkg installer for general use, which 
will refuse to install if the signature can't be verified.)



Plus, `make` requires a few dependencies. But when you install a package,
all the logic/doctor checks can be implemented on the `ports` binary level.
Install CLT, Xcode, check the environment, etc. Simple is better.


Sure.

- Josh

Re: Publicizing MacPorts

[Giuseppe 'ferdy' Miceli]

> On 22 May 2021, at 13:21, Artem Loenko via macports-dev 
>  wrote:
> 
> Hello there,
> 
> I agree with all the points about publicity (blog posts, Twitter, etc.). But 
> I want to share the opinion on MacPorts from a (power?) user who is aware of 
> the tool and “deep in my heart” believe that MacPorts is a better option 
> than, for example, Homebrew.

that is quite an interesting topic imho even if i fear it is quite hard to 
eviscerate since is prone to opinionated statements (just as example about the 
points you have listed, i agree with them and the rationales behind 
nevertheless i keep using macports and have no plan to switch to any other 
system :-)

> GUI APPLICATIONS
> 
> This is a controversial topic. As you know, you can install and manage GUI 
> macOS applications with so-called Homebrew `casks`[4]. From the user 
> perspective, there are no differences between CLI and GUI applications, and I 
> just want to manage applications I use with ONE package manager. In the case 
> of MacPorts, I cannot install even open-source applications (like Firefox, 
> NetNewsWire, etc.). 
> Yes, I understand that someone has to maintain such ports. But if we are 
> talking about publicity, new users and experience, it is vital to have at 
> least the most popular software on the list.

i definitively agree on that (e.g. i was elated when i found out iterm2 port 
availability).
i took note to try myself to try to port some of the applications i commonly 
use as soon as i have some spare time to test.

> BUNDLES
> 
> Homebrew supports bundles[3] where you can list all the software you use and 
> install it with a simple `brew bundle` command. It is a convenient way to 
> track a list of software you use, migrate between machines or set up remote 
> hardware on CI/CD. With MacPorts, I found only one way to do so – Makefile or 
> a shell script where I list all the packages I need. Not a big deal, you can 
> say, and it is true. But one of the reasons to use Homebrew over MacPorts.

actually this is possible and an easy task too as jmr just explained to me on 
irc :-)
you can have a look at the gimp package which is actual a bundle (or meta 
package or virtual package).
i have already written two dozen of “meta packages” which are helping me a lot 
to manage my different machines.

> Regards,
> Artem

cheers
—
ferdy

Re: Publicizing MacPorts [installation]

[Artem Loenko via macports-dev]

> On Sat, May 22, 2021 at 1:35 PM Ken Cunningham 
>  wrote:
>
> cd /tmp
> git clone -b release-2.7 https://github.com/macports/macports-base.git
> cd macports-base
> ./configure && make && sudo make install
>
> and then add to the $PATH as usual

If you ask me, `curl | sh` is a better option than `sudo make install`. 
Even if we compare them both as anti-patterns. 
Plus, `make` requires a few dependencies. But when you install a package, 
all the logic/doctor checks can be implemented on the `ports` binary level. 
Install CLT, Xcode, check the environment, etc. Simple is better.

On Sat, May 22, 2021 at 2:31 PM Joshua Root http://macports.org/> wrote:
>
> I think the best thing we could do to facilitate one-liner command
> line installation is set up a redirect so you can download the latest
> binary installer for your OS version without having to construct
> its not-so-easy-to-derive name yourself. It would then be simple to
> download the .pkg and feed it to installer(8).
>

Yes, this is the idea. And it seems manageable to implement. 
Proper short links, a few lines to produce/validate them in release scripts, 
profit.

P.S. I have started to build a simple version of such a script[1] based on the 
advice from the discussion.
Please, join if you desire to improve the script and propose it as a source for 
the one-liner we are talking about.

Regards,
Artem

[1] https://gist.github.com/dive/c4a51179aa96d229a32dd3492e5fdc2d

> On 22 May 2021, at 19:55, Jason Liu  wrote:
> 
> 
> On Sat, May 22, 2021 at 1:35 PM Ken Cunningham 
> mailto:ken.cunningham.web...@gmail.com>> 
> wrote:
> Yes, thanks for the tips! I am pretty sure that it is possible to automate it 
> one way or another. But my point is that it would be helpful to have a 
> one-liner to install MacPorts and maintain it as a part of the main 
> repository. 
> 
> This was of course suggested years ago as well, when homebrew first did it, 
> but at that time was that it was both not needed and not a useful addition to 
> MacPorts, if I recall the full email exchange correctly, so we let the idea 
> die.
> 
> I feel like having a one-liner to install MacPorts, similar to Homebrew, 
> would be incredibly useful, especially for people who are not tech savvy. It 
> seems that many of us on the mailing list, including myself, already have our 
> own home-grown scripts to automate installing MacPorts. One thing that I 
> particularly like about the Homebrew installer is that it automatically 
> installs the CLT... I've been doing something similar in my own MacPorts 
> install script for around a decade.
> 
> My script even automatically accepts the Xcode license by using a small chunk 
> of expect. I realize that from the perspective of the MacPorts developers, we 
> might not want to be taking over control of this step from the user. But from 
> personal experience as a sysadmin, even this seemingly minor step can be a 
> fairly high hurdle for people who are not tech savvy.
> 
> Another thing that my script tries to automate is to add /opt/local to 
> everyone's $PATH if the script detects that SIP is disabled.
> 
> On Sat, May 22, 2021 at 2:31 PM Joshua Root  > wrote:
> 
> I think the best thing we could do to facilitate one-liner command line 
> installation is set up a redirect so you can download the latest binary 
> installer for your OS version without having to construct its 
> not-so-easy-to-derive name yourself. It would then be simple to download the 
> .pkg and feed it to installer(8).
> 
> This would be incredibly useful, and would allow me to cut out around 40-50 
> lines of code from my MacPorts install script (which is currently 
> constructing the not-so-easy-to-derive name myself). A single permalink 
> redirect would also allow the installation instructions to be simplified on 
> the MacPorts website, instead of what's currently there:
> 
> 3. Install MacPorts for your version of the operating system:
> * macOS Big Sur v11 
> 
> * macOS Cataline v10.15 
> 
> * macOS Mojave v10.14 
> 
> * Older OS? See here. 
> -- 
> Jason Liu
> 
> 

Re: Publicizing MacPorts [installation]

[Bjarne D Mathiesen]

Joshua Root wrote:
> I think the best thing we could do to facilitate one-liner command line
> installation is set up a redirect so you can download the latest binary
> installer for your OS version without having to construct its
> not-so-easy-to-derive name yourself. It would then be simple to download
> the .pkg and feed it to installer(8).

so ... do we want to have a HomeBrew like instaler option ?

And if so : what type ? My solution installs directly from source & thus
by-passes the problem of finding the correct .pkg.

My complete script furthermore establishes a basis for maintainance (it
needs more --help options, but that can be fixed)

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: Publicizing MacPorts [installation]

[Bjarne D Mathiesen]

Joshua Root wrote:
> On 2021-5-23 03:12 , Bjarne D Mathiesen wrote:
>>
>>
>> Artem Loenko wrote:
>>> Yes, thanks for the tips! I am pretty sure that it is possible to
>>> automate it one way or another. But my point is that it would be
>>> helpful to have a one-liner to install MacPorts and maintain it as a
>>> part of the main repository.
>>>
>>
>> I'm 90% there there with this :
>> /usr/bin/env bash -c $( curl -fsSL --url
>> 'https://trac.macports.org/raw-attachment/wiki/howto/AdvancedDailyAdm/macports.bash'
>>
>> ) install
>>
>> When I'm running this as my normal un-privileged user,
>> it executes 邏 (and fails because it's un-privileged)
>>
>> !!! but !!! if I try this as my admin user, nothing happens 樂邏
>> There's some obscure security setting I presently can't fathom, because
>> I can run the script locally (without curl) without any issues. And it
>> does download - it just doesn't execute 樂邏樂
> 
> That's probably Gatekeeper and/or the Quarantine attribute doing its
> thing and stopping you from running arbitrary code straight from the
> web. curl | sh or the equivalent should be considered an antipattern

And yet HomeBrew uses it.

Now, how do I go about solving my original problem / finding the root
cause ?!?

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: Publicizing MacPorts [installation]

[Jason Liu]

On Sat, May 22, 2021 at 1:35 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:
>
> Yes, thanks for the tips! I am pretty sure that it is possible to automate
>> it one way or another. But my point is that it would be helpful to have a
>> one-liner to install MacPorts and maintain it as a part of the main
>> repository.
>
>
> This was of course suggested years ago as well, when homebrew first did
> it, but at that time was that it was both not needed and not a useful
> addition to MacPorts, if I recall the full email exchange correctly, so we
> let the idea die.
>

I feel like having a one-liner to install MacPorts, similar to Homebrew,
would be incredibly useful, especially for people who are not tech savvy.
It seems that many of us on the mailing list, including myself, already
have our own home-grown scripts to automate installing MacPorts. One thing
that I particularly like about the Homebrew installer is that it
automatically installs the CLT... I've been doing something similar in my
own MacPorts install script for around a decade.

My script even automatically accepts the Xcode license by using a small
chunk of expect. I realize that from the perspective of the MacPorts
developers, we might not want to be taking over control of this step from
the user. But from personal experience as a sysadmin, even this seemingly
minor step can be a fairly high hurdle for people who are not tech savvy.

Another thing that my script tries to automate is to add /opt/local to
everyone's $PATH if the script detects that SIP is disabled.

On Sat, May 22, 2021 at 2:31 PM Joshua Root  wrote:

>
> I think the best thing we could do to facilitate one-liner command
> line installation is set up a redirect so you can download the latest
> binary installer for your OS version without having to construct
> its not-so-easy-to-derive name yourself. It would then be simple to
> download the .pkg and feed it to installer(8).
>

This would be incredibly useful, and would allow me to cut out around 40-50
lines of code from my MacPorts install script (which is currently
constructing the not-so-easy-to-derive name myself). A single permalink
redirect would also allow the installation instructions to be simplified on
the MacPorts website, instead of what's currently there:

3. Install MacPorts for your version of the operating system:
* macOS Big Sur v11

* macOS Cataline v10.15

* macOS Mojave v10.14

* Older OS? See here. 

-- 
Jason Liu


On Sat, May 22, 2021 at 1:35 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> > Yes, thanks for the tips! I am pretty sure that it is possible to
> automate it one way or another. But my point is that it would be helpful to
> have a one-liner to install MacPorts and maintain it as a part of the main
> repository.
>
> This was of course suggested years ago as well, when homebrew first did
> it, but at that time was that it was both not needed and not a useful
> addition to MacPorts, if I recall the full email exchange correctly, so we
> let the idea die.
>
> I wrote up a MacPorts install script for Jeremy’s Xquartz project here <
> https://github.com/XQuartz/XQuartz/blob/master/install-or-update-macports.sh>
> that adds a bit more trickery he needed, but the basic guts was extremely
> simple and what I recommend to people who complain that MacPorts is
> extremely difficult to get installed and they claim to have spent hours and
> hours and hours trying to make it work:
>
> ==
>
> cd /tmp
> git clone -b release-2.7 https://github.com/macports/macports-base.git
> cd macports-base
> ./configure && make && sudo make install
>
>
> and then add to the $PATH as usual
>
> ==

Re: Publicizing MacPorts [installation]

[Joshua Root]

On 2021-5-23 03:12 , Bjarne D Mathiesen wrote:



Artem Loenko wrote:

Yes, thanks for the tips! I am pretty sure that it is possible to automate it 
one way or another. But my point is that it would be helpful to have a 
one-liner to install MacPorts and maintain it as a part of the main repository.



I'm 90% there there with this :
/usr/bin/env bash -c $( curl -fsSL --url
'https://trac.macports.org/raw-attachment/wiki/howto/AdvancedDailyAdm/macports.bash'
) install

When I'm running this as my normal un-privileged user,
it executes 邏 (and fails because it's un-privileged)

!!! but !!! if I try this as my admin user, nothing happens 樂邏
There's some obscure security setting I presently can't fathom, because
I can run the script locally (without curl) without any issues. And it
does download - it just doesn't execute 樂邏樂


That's probably Gatekeeper and/or the Quarantine attribute doing its 
thing and stopping you from running arbitrary code straight from the 
web. curl | sh or the equivalent should be considered an antipattern (at 
one point there was even a tumblr hall of shame for it.)


I think the best thing we could do to facilitate one-liner command line 
installation is set up a redirect so you can download the latest binary 
installer for your OS version without having to construct its 
not-so-easy-to-derive name yourself. It would then be simple to download 
the .pkg and feed it to installer(8).


- Josh

Re: Publicizing MacPorts [installation]

[Ken Cunningham]

> Yes, thanks for the tips! I am pretty sure that it is possible to automate it 
> one way or another. But my point is that it would be helpful to have a 
> one-liner to install MacPorts and maintain it as a part of the main 
> repository. 

This was of course suggested years ago as well, when homebrew first did it, but 
at that time was that it was both not needed and not a useful addition to 
MacPorts, if I recall the full email exchange correctly, so we let the idea die.

I wrote up a MacPorts install script for Jeremy’s Xquartz project here 
 
that adds a bit more trickery he needed, but the basic guts was extremely 
simple and what I recommend to people who complain that MacPorts is extremely 
difficult to get installed and they claim to have spent hours and hours and 
hours trying to make it work:

==

cd /tmp
git clone -b release-2.7 https://github.com/macports/macports-base.git
cd macports-base
./configure && make && sudo make install


and then add to the $PATH as usual

==

Re: Publicizing MacPorts [installation]

[Bjarne D Mathiesen]

Artem Loenko wrote:
> Yes, thanks for the tips! I am pretty sure that it is possible to automate it 
> one way or another. But my point is that it would be helpful to have a 
> one-liner to install MacPorts and maintain it as a part of the main 
> repository.
> 

I'm 90% there there with this :
/usr/bin/env bash -c $( curl -fsSL --url
'https://trac.macports.org/raw-attachment/wiki/howto/AdvancedDailyAdm/macports.bash'
) install

When I'm running this as my normal un-privileged user,
it executes 邏 (and fails because it's un-privileged)

!!! but !!! if I try this as my admin user, nothing happens 樂邏
There's some obscure security setting I presently can't fathom, because
I can run the script locally (without curl) without any issues. And it
does download - it just doesn't execute 樂邏樂

but the following is presently a more complete solution, that also
provides the script for further use.

#!/usr/bin/env bash

declare
baseURL='https://trac.macports.org/raw-attachment/wiki/howto/AdvancedDailyAdm'

mkdir -p MacPorts
cd MacPorts
curl -O --url "${baseURL}/portDefaults"
curl -O --url "${baseURL}/macports.bash"
chmod +x *.bash
sudo macports.bash setpaths
sudo macports.bash install
macports.bash --help


-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: Publicizing MacPorts [installation]

[Artem Loenko via macports-dev]

Yes, thanks for the tips! I am pretty sure that it is possible to automate it 
one way or another. But my point is that it would be helpful to have a 
one-liner to install MacPorts and maintain it as a part of the main repository.

Regards,
Artem

> On 22 May 2021, at 15:01, Bjarne D Mathiesen  wrote:
> 
> 
> 
> Joshua Root wrote:
>> On 2021-5-22 23:17 , Bjarne D Mathiesen wrote:
>>> 
>>> My own installation script looks something like this :
>>> 
>>> #!/usr/bin/env bash
>>> 
>>> prefix=$(1:-'/opt/local')
>>> version=${2:-'2.7.0'}
>> 
>> I you want to automatically use the latest version, it can be found in
>> .
>> 
>> - Josh
>> 
> 
> so something like this :
> declare version=$( curl --url
> 'https://raw.githubusercontent.com/macports/macports-base/master/config/RELEASE_URL'
> )
> version=${version##*/v}
> 
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ---
> denne besked er skrevet i et totalt M$-frit miljø
> OpenCore + macOS 10.15.7 Catalina
> MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
> ATI Radeon RX 590 8 GB

Re: Publicizing MacPorts [installation]

[Bjarne D Mathiesen]

Joshua Root wrote:
> On 2021-5-22 23:17 , Bjarne D Mathiesen wrote:
>>
>> My own installation script looks something like this :
>>
>> #!/usr/bin/env bash
>>
>> prefix=$(1:-'/opt/local')
>> version=${2:-'2.7.0'}
> 
> I you want to automatically use the latest version, it can be found in
> .
> 
> - Josh
> 

so something like this :
declare version=$( curl --url
'https://raw.githubusercontent.com/macports/macports-base/master/config/RELEASE_URL'
)
version=${version##*/v}


-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: Publicizing MacPorts [installation]

[Joshua Root]

On 2021-5-22 23:17 , Bjarne D Mathiesen wrote:


My own installation script looks something like this :

#!/usr/bin/env bash

prefix=$(1:-'/opt/local')
version=${2:-'2.7.0'}


I you want to automatically use the latest version, it can be found in 
.


- Josh

Re: Publicizing MacPorts [installation]

[Bjarne D Mathiesen]

Artem Loenko via macports-dev wrote:
> INSTALLATION
> 
> The current process is described well[1], but it is almost impossible to
> automate it. For a tool that supposes to be a CLI to manage everything,
> this is a disadvantage for me. Yes, I can install MacPorts from the
> command-line with something like this in my Makefile:
> 
...

My own installation script looks something like this :

#!/usr/bin/env bash

prefix=$(1:-'/opt/local')
version=${2:-'2.7.0'}

if [ ! -e MacPorts-${version}.tar.gz ]
then
curl -L -O --url
"https://github.com/macports/macports-base/releases/download/v${version}/MacPorts-${version}.tar.gz;
fi

rm  -rf  ./MacPorts-${version}
tar -zxf   MacPorts-${version}.tar.gz 2>/dev/null \
|| { echo "error expanding MacPorts-${version}.tar.gz" ; exit }

cd MacPorts-${version}
CC=/usr/bin/cc ./configure \
 --prefix=/opt/local \
 --with-install-user=root \
 --with-install-group=admin \
 --with-directory-mode=0755 \
 --enable-readline \
&& make SELFUPDATING=1 \
&& make install SELFUPDATING=1 \
|| { echo "error compiling MacPorts-${version}" ; exit }

# update MacPorts itself
${prefix}/bin/port -dN selfupdate

# let's get bash, zsh & nano
${prefix}/bin/port -N install bash  && echo "${prefix}/bin/bash" >>
/etc/shells
${prefix}/bin/port -N install zsh   && echo "${prefix}/bin/zsh"  >>
/etc/shells
${prefix}/bin/port -N install nano

# cleanup
cd ..
rm  -rf  ./MacPorts-${version}

(this is actuallly part of a bigger script system I (desperately) try to
maintain at https://trac.macports.org/wiki/howto/AdvancedDailyAdm )

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: Publicizing MacPorts [bundles]

[Bjarne D Mathiesen]

Artem Loenko via macports-dev wrote:
> BUNDLES
> 
> Homebrew supports bundles[3] where you can list all the software you use
> and install it with a simple `brew bundle` command. It is a convenient
> way to track a list of software you use, migrate between machines or set
> up remote hardware on CI/CD. With MacPorts, I found only one way to do
> so – Makefile or a shell script where I list all the packages I need.
> Not a big deal, you can say, and it is true. But one of the reasons to
> use Homebrew over MacPorts.

I've got a problem w/ bundles : they -almost- never install -or- do what
I need 樂

Lets take something like the LAMP stack:
L : it's a given (macOS)
A : apache24 ; ngix
M : MySQL ; Percona ; MariaDB ; Postgresql ; sqlite
P : php72, php73, php74, php80 ; python ; perl

and for php in particular : which extensions are needed ?
as to the different php-versions : I had to play around w/ Magento &
Typo3. At that time, I had php73 installed ; BUT they had only certifed
themselves up to php72 and simply refused to install under php73, so I
had to || install php72 and modify my Apache24 conf ; & presently
WordPress doesn't recommend php80; & one of the modules WordPress really
recommends (php80-imagick) isn't available yet for php80, but can be
installed from source [thread: Re: [errors] php80-imagick ; 21/01/2021]

So : bundles is a nice idea; but I regard them as for the intermediate
user - not the advanced.

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
OpenCore + macOS 10.15.7 Catalina
MacPro 2010 ; 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC
ATI Radeon RX 590 8 GB

Re: Publicizing MacPorts

[Artem Loenko via macports-dev]

Hello there,

I agree with all the points about publicity (blog posts, Twitter, etc.). But I 
want to share the opinion on MacPorts from a (power?) user who is aware of the 
tool and “deep in my heart” believe that MacPorts is a better option than, for 
example, Homebrew.

INSTALLATION

The current process is described well[1], but it is almost impossible to 
automate it. For a tool that supposes to be a CLI to manage everything, this is 
a disadvantage for me. Yes, I can install MacPorts from the command-line with 
something like this in my Makefile:

```
macports: ## Install/Upgrade MacPorts
ifeq (, $(shell which port))
$(eval TEMP_PKG := $(shell mktemp -t macports).pkg)
curl --silent --output $(TEMP_PKG) --remote-name 
https://distfiles.macports.org/MacPorts/MacPorts-2.6.4_1-11-BigSur.pkg 

sudo installer -pkg $(TEMP_PKG) -target /
rm -Rf $(TEMP_PKG)
```

But then I have to maintain the URL, update it if I do not want to migrate, etc.
You can compare it with the Homebrew approach[2]:

```
/bin/bash -c "$(curl -fsSL 
https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh 
)”
```

It may sound like a minor issue. But simplicity and efficiency are important, I 
believe. From my point of view, it is easy to improve it:
1. Have a symlink to the latest available version (e.g. 
https://distfiles.macports.org/latest-macos-11.pkg 
)
2. Have a script that will detect the macOS version on the machine (`sw_vers 
-productVersion` or something) and download the proper package
3. Run the installer with `installer -pkg …`

GUI APPLICATIONS

This is a controversial topic. As you know, you can install and manage GUI 
macOS applications with so-called Homebrew `casks`[4]. From the user 
perspective, there are no differences between CLI and GUI applications, and I 
just want to manage applications I use with ONE package manager. In the case of 
MacPorts, I cannot install even open-source applications (like Firefox, 
NetNewsWire, etc.). 
Yes, I understand that someone has to maintain such ports. But if we are 
talking about publicity, new users and experience, it is vital to have at least 
the most popular software on the list.

BUNDLES

Homebrew supports bundles[3] where you can list all the software you use and 
install it with a simple `brew bundle` command. It is a convenient way to track 
a list of software you use, migrate between machines or set up remote hardware 
on CI/CD. With MacPorts, I found only one way to do so – Makefile or a shell 
script where I list all the packages I need. Not a big deal, you can say, and 
it is true. But one of the reasons to use Homebrew over MacPorts.

CONCLUSIONS

Why I like MacPorts but use Homebrew? Because it is a convenient way to manage 
your packages seamlessly (starting from the installation process and to the 
point of how you maintain the list of software you use).
And again, from my point of view, publicity could (and should) help, but the 
user experience is an important aspect as well. For now, even the statement 
from the main page – Install and upgrade open-source software on macOS – is not 
entirely true, unfortunately.

P.S. Do not get me wrong. You do a great job maintaining the tool for many 
years; thank you for this! And there are cases when I prefer MacPorts over 
other solutions. Please, consider this message as my attempt to help and 
contribute to the discussion.


[1] https://www.macports.org/install.php 
[2] https://brew.sh/ 
[3] https://github.com/Homebrew/homebrew-bundle 

[4] https://github.com/Homebrew/homebrew-cask 


Regards,
Artem

Re: Publicizing MacPorts

[Saagar Jha]

I’m not a MacPorts core maintainer or anything, nor am I a PR expert, but (for 
various reasons) I happen to interact with a lot of users who are curious about 
macOS package managers. Here’s a couple of takeaways I have from those 
conversations, as well as my thoughts on what MacPorts could do in light of 
them.

The biggest issue that I think MacPorts faces is that it has an image of being 
“old and dead”, especially compared to vibrant alternatives such as Homebrew. 
Of course, much of the response I get to MacPorts is “I’ve never heard of it” 
but even from the people who know what it is I hear a lot of “I used that 
several years ago, but then I switched package managers…wait, it’s still 
around?” There are a couple of other undesirable impressions: that MacPorts is 
the place that’s missing packages, or has ancient copies of them, or that 
MacPorts compiles everything from source (there was a thread on this list just 
recently on this topic). Obviously these are not quite true, nor are they 
things that one would want associated with MacPorts. I think the solution to 
this is two-pronged.

The first angle here is one of advocacy: MacPorts is obviously *not* dead, but 
nobody knows about it, because there is nothing to tell them about it. I think 
maintaining even a minimal social media presence would do much here. MacPorts 
should capitalize on its strengths and announce them when appropriate. This 
doesn’t have to be a lot of effort (and I would of course be happy to help with 
it, if that would be useful)–it’s things like spending an hour on a blog post 
with details of what’s in a new release, or posting relevant updates on Twitter 
when appropriate. Uncompromising M1 support has been mentioned in this thread 
already as a major plus for MacPorts, and I fully agree; nothing would have 
sold “this package manager is alive and well” better than showing how well 
MacPorts supported Apple silicon from the get-go. As another datapoint, compare 
https://news.ycombinator.com/from?site=brew.sh 
 to 
https://news.ycombinator.com/from?site=macports.org 
; and keep in mind that 
Hacker News is one of the few places on the internet where a Homebrew mention 
is often followed by favorable one for MacPorts. There’s probably some new OSes 
and hardware dropping later this year, perhaps it might be wise to highlight 
that MacPorts runs on them when they come out.

The other part is technical: MacPorts actually needs to live up to what we are 
trying to sell it as. If the website has pages that haven’t been restyled since 
2008, people are going to think that nobody has touched them since then, which 
isn’t how you want to present yourself if you’re an actively maintained 
project. (I know there has been work in the past in this area–I guess we just 
need to build on it.) If you try to install a package and the project tells you 
to use Homebrew to get it on macOS, or you install it in MacPorts and it’s a 
version from four years ago, then I think it is natural to end up with the idea 
that MacPorts doesn’t have packages you want. Where possible, I think we should 
track statistics of which of our packages livecheck as up-to-date, or how good 
our coverage is of things from other package managers. I know this is work and 
perhaps there is not enough manpower to handle it, but perhaps they can help 
inform what should be focused on.

One final thing: I think certain strategies might be counterproductive or 
unhelpful at this stage. Contacting the press is one way to get your message 
out, but it’s a fair bit of work, and fairly rare among software projects 
regardless. Other package managers get publicity just fine without it, and 
frankly if you’re already doing your publicity job well people will write about 
your thing of their own accord. Also, treating Homebrew and other package 
managers as “competition” where they have to lose is, IMO, an unhealthy way of 
looking at the situation. Homebrew caters to many developers and does a very 
good job at it, and I honestly believe that many of them would not enjoy using 
MacPorts. The right way to frame this, in my mind, is to recognize that 
Homebrew et al. have their own policies and ways of doing things, and MacPorts 
has its own. I don’t see us as trying to “steal” users away from other package 
managers–instead, the goal should be to identify those who are unhappy with 
them and help them realize that there are alternatives that might better suit 
their needs. For Homebrew at least I honestly believe that they would be glad 
to send their underserved users our way. We just need to work to make them 
aware of this choice.

Regards,
Saagar Jha

> On Apr 20, 2021, at 12:03, Rainer Müller  > wrote:
> 
> On 20/04/2021 12.40, Steven Smith wrote:
>> That’s begging the question of an effective communications strategy. A 
>> distributed model 

Re: Publicizing MacPorts

[Nils Breunese]

Georges Martin  wrote:

> - What if a port is not building on M1 because upstream is not ready yet? 
> (libffi, openjdk16, ghc comes to mind)

The openjdk16 port in MacPorts indeed doesn’t support arm64 yet, because 
AdoptOpenJDK hasn’t released their arm64 version for macOS yet.

I have added openjdk*-zulu ports for Azul Zulu OpenJDK to MacPorts recently and 
Azul does already provide arm64 versions for macOS: 
https://www.azul.com/downloads/zulu-community/?os=macos=arm-64-bit=jdk
 


I can probably add arm64 versions for openjdk*-zulu when my Mac is back from 
getting a new screen (hopefully next week), although I won’t be able to test 
myself, because I don’t have an M1 machine. Feel free to send a PR for adding 
arm64 ports for Azul Zulu yourself if you can add and test them.

Nils.

Re: Publicizing MacPorts

[Mojca Miklavec]

On Sat, 24 Apr 2021 at 13:04, Georges Martin  wrote:
>
> Le 22 avr. 2021 à 17:46, Steven Smith  a écrit :
>
> Another reason major news like M1 support must be announced.
>
>
> May I ask: how do we *define* "M1 support" in MacPorts? What are the 
> *metrics* used to support that statement?
>
> - How does the MacPorts base "support the M1"? (I know I had to install it 
> from git then switch to the master branch for other reasons -- not a typical 
> user installation)
>
> - Is it when you set buildfromsource to always, build_arch to arm64 and 
> everything run smoothly afterwards? :-)

You go to https://www.macports.org/install.php, download the pkg and run it.

It's usually before the official release of the new OS that one needs
to install MacPorts base from source, but that's mainly because one
needs to sign some kind of agreement with Apple that prevents
developers from doing certain things and reveal details about the beta
to public. Or at least it's my understanding that we may not
distribute binaries for beta versions before the official release.

Building base from source is useful for anyone who wants to help with
testing or development though.

> - How does a port "supports the M1"? Is it when it can be built, tested and 
> installed on a M1? Even if it's just compiled as x86_64 and running on 
> Rosetta? Or is it when it can be successfully built, tested and installed as 
> native and/or +universal  on both M1 and Intel?

Yes, when it builds without any hassle & intervention on M1, and the
resulting software works. Bonus points if it comes as a binary. If
certain software cannot be built natively, but still works as x86_64,
I would also call this supported. But keep in mind that it's actually
a lot more work to ensure that a particular port can be built for
another architecture, than it is to make it build natively. Plenty of
ports just worked, while some other software may never get ported
properly.

> - How many ports are building on M1 today? (can a user do a search on 
> architecture on ports.macports.org?) Before installing, how can a user know 
> if a port is building/testing successfully on M1? (can he do a `port info 
> --name --supported-archs` on a port?)

You can go to
https://ports.macports.org/ports/all_builds/
and select 11_arm64 as the builder (it's a pity that we don't have a
direct link, but that could be added).

The arm64 builder was missing for a short while (it's 270 commits
behind at the moment of writing), but it's slowly catching up:
https://build.macports.org/waterfall?tag=11
and some ports that haven't seen any updates in a long while might not
have been attempted to build (that might happen in a few days).

> - What if a port is not building on M1 because upstream is not ready yet? 
> (libffi, openjdk16, ghc comes to mind) What if ports are not building because 
> major dependencies are not? (thinking of you, libffi) Is it documented 
> anywhere?

If either upstream is not ready, or if one of the dependencies (even
if that dependency means a broken compiler) is broken, then the port
is broken. The best reference we have at the moment is probably
https://ports.macports.org/port/ghc/

You can combine the information from:
- port health that tells you whether the port built successfully on
the buildbot worker in question
- installation statistics submitted by users (where you can see that
nobody has ghc installed on arm64, for example)
- the list of Trac tickets

> - How are M1 porting priorities defined? Do we have "M1 priorities" or "M1 
> call for help" for maintainers? Is there a M1 "Hot Problems" page for users 
> and maintainers like we have for macOS releases?

We don't have any "M1 priorities" list at the moment.
We have some kind of approximation of the most popular ports here:

https://ports.macports.org/statistics/ports/?days=30=-total_count=-req_count=port
and I believe that we added some information about whether the port is
broken or not to the new ports page that hasn't been deployed yet (I'm
not 100% sure).

> To be clear: I am **not** complaining. I switched to M1 a month and a half 
> ago and decided to contribute to the effort as much as I can: I installed 
> from git, set up buildfromsource to always and build_arch to arm64, then 
> switched to git master. After Ken's call for help on ICU, I set my variants 
> to +universal, recompiled everything that could be (but had to stop because 
> of libffi...).  I'm trying to natively build all the ports I was using on 
> Catalina/x86_64, I'm not there yet (today, py{38,39}-pandas do not build 
> anymore because of OpenBLAS...) and I am not complaining: it's part of the 
> game... :-)

One of the problems with "call for help" at the moment is that we have
way too many tickets open, and it's basically impossible to
figure out which ones are most important to look into.

For anyone possessing a M1 mac probably the best way to contribute by
far is to help build those ports which that 

Re: Publicizing MacPorts

[Christopher Jones]

Hi,

> On 24 Apr 2021, at 12:04 pm, Georges Martin  wrote:
> 
>> Le 22 avr. 2021 à 17:46, Steven Smith > > a écrit :
>> 
>> Another reason major news like M1 support must be announced.
> 
> 
> May I ask: how do we *define* "M1 support" in MacPorts? What are the 
> *metrics* used to support that statement?
> 
> - How does the MacPorts base "support the M1"? (I know I had to install it 
> from git then switch to the master branch for other reasons -- not a typical 
> user installation) 

port runs natively on M1 machines, and can build ports natively as well. Also, 
as far as I am aware the macOS11 pkg installer at 

https://www.macports.org/install.php

natively supports both intel and arm (disclaimer, I always build base from 
source myself, as I work with the a git checkout of base, so I haven’t actually 
run the above myself. I also am not lucky enough to have an M1 machine at this 
time). 

> - Is it when you set buildfromsource to always, build_arch to arm64 and 
> everything run smoothly afterwards? :-)

11_arm64 is support to the same degree as other OSes. The buildbots build for 
this arch, and when possible distribute binary installation tarballs for it. 
Always building from source is not required.

> 
> - How does a port "supports the M1"? Is it when it can be built, tested and 
> installed on a M1? Even if it's just compiled as x86_64 and running on 
> Rosetta? Or is it when it can be successfully built, tested and installed as 
> native and/or +universal  on both M1 and Intel?

I believe we consider support to be building natively for arm. 11_x86_64 and 
11_arm64 are separate platforms, just like other OSes are. Yes, you can if you 
want build ports universal, but just like on other OSes (eg. 32/64 bit, or 
intel/PPC) its port dependent if this works or not.

> 
> - How many ports are building on M1 today? (can a user do a search on 
> architecture on ports.macports.org ?) Before 
> installing, how can a user know if a port is building/testing successfully on 
> M1? (can he do a `port info --name --supported-archs` on a port?)

I am not sure if that site can give you an overall number of ports currently 
working on arm. But you can check the stats for individual ports. Note though, 
the info there is sometimes a little out of date unfortunately, e.g. there has 
recently been issues with the site not correctly important build logs from the 
builders.

> - What if a port is not building on M1 because upstream is not ready yet? 
> (libffi, openjdk16, ghc comes to mind) What if ports are not building because 
> major dependencies are not? (thinking of you, libffi) Is it documented 
> anywhere?

Not systematically/automatically. If someone has submitted a ticket you can 
search for it, e.g. starting at 

https://trac.macports.org/wiki/BigSurProblems 


> 
> - How are M1 porting priorities defined? Do we have "M1 priorities" or "M1 
> call for help" for maintainers? Is there a M1 "Hot Problems" page for users 
> and maintainers like we have for macOS releases?

See above. Priority is mostly based on personal opinion. If someone cares 
enough about a port they will work on it.

The above is just my thoughts, not an ‘official stance’ in any way….

cheers Chris

> 
> 
> To be clear: I am **not** complaining. I switched to M1 a month and a half 
> ago and decided to contribute to the effort as much as I can: I installed 
> from git, set up buildfromsource to always and build_arch to arm64, then 
> switched to git master. After Ken's call for help on ICU, I set my variants 
> to +universal, recompiled everything that could be (but had to stop because 
> of libffi...).  I'm trying to natively build all the ports I was using on 
> Catalina/x86_64, I'm not there yet (today, py{38,39}-pandas do not build 
> anymore because of OpenBLAS...) and I am not complaining: it's part of the 
> game... :-)
> 
> 
> But: I'm afraid this "marketing" effort could backfire if we don't clearly 
> define what "M1 support" means and provide some metrics to maintainers and 
> users. As well as news sites.
> 
> 
> G.



smime.p7s
Description: S/MIME cryptographic signature

Re: Publicizing MacPorts

[Georges Martin]

> Le 22 avr. 2021 à 17:46, Steven Smith  a écrit :
> 
> Another reason major news like M1 support must be announced.


May I ask: how do we *define* "M1 support" in MacPorts? What are the *metrics* 
used to support that statement?

- How does the MacPorts base "support the M1"? (I know I had to install it from 
git then switch to the master branch for other reasons -- not a typical user 
installation) 

- Is it when you set buildfromsource to always, build_arch to arm64 and 
everything run smoothly afterwards? :-)

- How does a port "supports the M1"? Is it when it can be built, tested and 
installed on a M1? Even if it's just compiled as x86_64 and running on Rosetta? 
Or is it when it can be successfully built, tested and installed as native 
and/or +universal  on both M1 and Intel?

- How many ports are building on M1 today? (can a user do a search on 
architecture on ports.macports.org ?) Before 
installing, how can a user know if a port is building/testing successfully on 
M1? (can he do a `port info --name --supported-archs` on a port?)

- What if a port is not building on M1 because upstream is not ready yet? 
(libffi, openjdk16, ghc comes to mind) What if ports are not building because 
major dependencies are not? (thinking of you, libffi) Is it documented anywhere?

- How are M1 porting priorities defined? Do we have "M1 priorities" or "M1 call 
for help" for maintainers? Is there a M1 "Hot Problems" page for users and 
maintainers like we have for macOS releases?


To be clear: I am **not** complaining. I switched to M1 a month and a half ago 
and decided to contribute to the effort as much as I can: I installed from git, 
set up buildfromsource to always and build_arch to arm64, then switched to git 
master. After Ken's call for help on ICU, I set my variants to +universal, 
recompiled everything that could be (but had to stop because of libffi...).  
I'm trying to natively build all the ports I was using on Catalina/x86_64, I'm 
not there yet (today, py{38,39}-pandas do not build anymore because of 
OpenBLAS...) and I am not complaining: it's part of the game... :-)


But: I'm afraid this "marketing" effort could backfire if we don't clearly 
define what "M1 support" means and provide some metrics to maintainers and 
users. As well as news sites.


G.

Publicizing MacPorts

[Steven Smith]


> 
> Ironically, MacPorts is claimed to have "initial or beta support" for
> Apple silicon on https://isapplesiliconready.com/

Another reason major news like M1 support must be announced.

As a volunteer, I could quickly post a correction, but in doing so this website 
reasonably asks for a reference link, for which there is none because MacPorts 
has made no such announcement.

If MacPorts doesn’t tell its story, someone else will.

> On Apr 22, 2021, at 10:09, Zero King  wrote:
> 
> On Mon, Apr 19, 2021 at 01:24:51PM +0200, Mojca Miklavec wrote:
>>> On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:
>>> If a comparable announcement to this was made for MacPorts, I missed it:
>>> https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/
>> We never made any announcement since it basically "worked from day 1"
>> (almost), and we never had any specific point in time when support for
>> M1 was significantly improved. (We probably needed an upgrade of
>> MacPorts base, but that happened very soon.)
>> We should probably be publicising that MacPorts works just fine with
>> M1 more aggressively from the very beginning.
> 
> Ironically, MacPorts is claimed to have "initial or beta support" for
> Apple silicon on https://isapplesiliconready.com/ (top search result for
> "is m1 ready" on Google), while Homebrew is "fully compatible".
> 
>> If anyone is willing to volunteer to do PR for MacPorts ...
>> Mojca

Re: Publicizing MacPorts

[Zero King]

On Mon, Apr 19, 2021 at 01:24:51PM +0200, Mojca Miklavec wrote:

On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:


If a comparable announcement to this was made for MacPorts, I missed it:

https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/


We never made any announcement since it basically "worked from day 1"
(almost), and we never had any specific point in time when support for
M1 was significantly improved. (We probably needed an upgrade of
MacPorts base, but that happened very soon.)

We should probably be publicising that MacPorts works just fine with
M1 more aggressively from the very beginning.


Ironically, MacPorts is claimed to have "initial or beta support" for
Apple silicon on https://isapplesiliconready.com/ (top search result for
"is m1 ready" on Google), while Homebrew is "fully compatible".


If anyone is willing to volunteer to do PR for MacPorts ...

Mojca

Re: Publicizing MacPorts

[Jason Liu]

On Wed, Apr 21, 2021 at 10:42 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> A set of pages with some screenshots of some of the cool GUI software and
> games, like SNAP has for Ubuntu.


To piggyback off Ken's statement, as a part of the modernization efforts
for the website, it would be nice to have a section or infobox on the
MacPorts front page with either a featured "App of the Day" or "App of the
Week", similar to what is in the iOS/Mac App Store. Just off the top of my
head, I can think of over a dozen candidates, including GIMP, Inkscape,
VLC, Blender, Audacity, KeePassXC, Battle for Wesnoth, SuperTuxKart, etc.
We could even automatically populate the text of the infobox with the
long_description directly from the portfiles. Add some pretty screenshots,
and of course, the bottom would always say something like:

To install this app using MacPorts, run this command

sudo port install gimp

in a terminal window.

We could even make it so that if a visitor to the website clicks on the
text for the "sudo port install" line, it automatically copies the command
to their clipboard. I think that just adding this one thing could make the
MacPorts website feel more lively and dynamic.

I can also help with a redesign or modernization of the public-facing
website. I did some professional web design work to put myself through
college. I'm more of a web programmer than a graphic designer, but taking
good-looking screenshots of apps shouldn't be too difficult. Even better
would be to scrape the screenshots directly from the project authors'
websites, since they are much more likely to have up-to-date screenshots
whenever they make changes to their UI.

-- 
Jason Liu


On Wed, Apr 21, 2021 at 10:42 PM Ken Cunningham <
ken.cunningham.web...@gmail.com> wrote:

> various people have come along with some good ideas over the five years
> I’ve been around.
>
> A set of pages with some screenshots of some of the cool GUI software and
> games, like SNAP has for Ubuntu.
>
> A rewrite of the very old and dated and cobwebby website.
>
> To be honest —  these people in the end have not been encouraged to
> proceed. “I’ll get to that” or “Who is going to do that?” or “Why should we
> do that?” are far more common responses.
>
> So — start there, I would volunteer.
>
> Ken

Re: Publicizing MacPorts

[Ken Cunningham]

various people have come along with some good ideas over the five years I’ve 
been around.

A set of pages with some screenshots of some of the cool GUI software and 
games, like SNAP has for Ubuntu.

A rewrite of the very old and dated and cobwebby website.

To be honest —  these people in the end have not been encouraged to proceed. 
“I’ll get to that” or “Who is going to do that?” or “Why should we do that?” 
are far more common responses.

So — start there, I would volunteer.

Ken

Re: Publicizing MacPorts

[Steven Smith]

> MacPorts faces is that it has an image of being “old and dead”, especially 
> compared to vibrant alternatives such as Homebrew.

This is the issue. If you don’t tell your own story, others will. MacPorts is 
not telling its own story.

Saagar’s consequent suggestions are also excellent: announcements/social media, 
statistics, website, in my view in that order of importance.


> On Apr 21, 2021, at 08:01, Saagar Jha  wrote:
> 
> I’m not a MacPorts core maintainer or anything, nor am I a PR expert, but 
> (for various reasons) I happen to interact with a lot of users who are 
> curious about macOS package managers. Here’s a couple of takeaways I have 
> from those conversations, as well as my thoughts on what MacPorts could do in 
> light of them.
> 
> The biggest issue that I think MacPorts faces is that it has an image of 
> being “old and dead”, especially compared to vibrant alternatives such as 
> Homebrew. Of course, much of the response I get to MacPorts is “I’ve never 
> heard of it” but even from the people who know what it is I hear a lot of “I 
> used that several years ago, but then I switched package managers…wait, it’s 
> still around?” There are a couple of other undesirable impressions: that 
> MacPorts is the place that’s missing packages, or has ancient copies of them, 
> or that MacPorts compiles everything from source (there was a thread on this 
> list just recently on this topic). Obviously these are not quite true, nor 
> are they things that one would want associated with MacPorts. I think the 
> solution to this is two-pronged.
> 
> The first angle here is one of advocacy: MacPorts is obviously *not* dead, 
> but nobody knows about it, because there is nothing to tell them about it. I 
> think maintaining even a minimal social media presence would do much here. 
> MacPorts should capitalize on its strengths and announce them when 
> appropriate. This doesn’t have to be a lot of effort (and I would of course 
> be happy to help with it, if that would be useful)–it’s things like spending 
> an hour on a blog post with details of what’s in a new release, or posting 
> relevant updates on Twitter when appropriate. Uncompromising M1 support has 
> been mentioned in this thread already as a major plus for MacPorts, and I 
> fully agree; nothing would have sold “this package manager is alive and well” 
> better than showing how well MacPorts supported Apple silicon from the 
> get-go. As another datapoint, compare 
> https://news.ycombinator.com/from?site=brew.sh to 
> https://news.ycombinator.com/from?site=macports.org; and keep in mind that 
> Hacker News is one of the few places on the internet where a Homebrew mention 
> is often followed by favorable one for MacPorts. There’s probably some new 
> OSes and hardware dropping later this year, perhaps it might be wise to 
> highlight that MacPorts runs on them when they come out.
> 
> The other part is technical: MacPorts actually needs to live up to what we 
> are trying to sell it as. If the website has pages that haven’t been restyled 
> since 2008, people are going to think that nobody has touched them since 
> then, which isn’t how you want to present yourself if you’re an actively 
> maintained project. (I know there has been work in the past in this area–I 
> guess we just need to build on it.) If you try to install a package and the 
> project tells you to use Homebrew to get it on macOS, or you install it in 
> MacPorts and it’s a version from four years ago, then I think it is natural 
> to end up with the idea that MacPorts doesn’t have packages you want. Where 
> possible, I think we should track statistics of which of our packages 
> livecheck as up-to-date, or how good our coverage is of things from other 
> package managers. I know this is work and perhaps there is not enough 
> manpower to handle it, but perhaps they can help inform what should be 
> focused on.
> 
> One final thing: I think certain strategies might be counterproductive or 
> unhelpful at this stage. Contacting the press is one way to get your message 
> out, but it’s a fair bit of work, and fairly rare among software projects 
> regardless. Other package managers get publicity just fine without it, and 
> frankly if you’re already doing your publicity job well people will write 
> about your thing of their own accord. Also, treating Homebrew and other 
> package managers as “competition” where they have to lose is, IMO, an 
> unhealthy way of looking at the situation. Homebrew caters to many developers 
> and does a very good job at it, and I honestly believe that many of them 
> would not enjoy using MacPorts. The right way to frame this, in my mind, is 
> to recognize that Homebrew et al. have their own policies and ways of doing 
> things, and MacPorts has its own. I don’t see us as trying to “steal” users 
> away from other package managers–instead, the goal should be to identify 
> those who are unhappy with them and help them realize that there 

Re: Publicizing MacPorts

[Steven Smith]

> If you pledge to handle this kind of marketing, I would have no problem to 
> hand out an @macports.org address for that.

Thank you for the confidence. There are posts I could and would write about the 
utility specific ports that are only available from MacPorts. But I’m honestly 
not the right person to get out the high-level, timely, and accurate 
announcements of the sort we’ve been discussing. 

There’s been a few good ideas in this thread that stand out to include in a 
feed:
• High-level, timely, and accurate announcements, .e.g. “MacPorts supports the 
new Apple silicon M1”
• Blog posts about capabilities, e.g. “here’s a useful port you may want to 
know about,” or “here’s a useful port command.”
• Noteworthy and insightful statistics, e.g. total number of ports, total 
number of compiled binaries, total number supported on Apple silicon, total 
supported on Big Sur, total supported on Tiger, Big Ten list of popularity, the 
port with the longest dependency chain—stuff like that, reduced to a dashboard. 
• Calls for MacPorts meetings, summer of code recruiting, and other calendar 
events.

> We have the news section on the website [1]. Posts can be submitted with pull 
> requests to the corresponding repository [2]. At the moment, it is only in 
> use for release announcements that are also posted on macports-announce [3].

Some feedback:

If the News section is intended to include other items like this listed above, 
then that must be made clear to the user community on this page and on GitHub. 
Right now, contributed content is the exclusive domain of the top MacPorts 
managers: https://github.com/macports/macports.github.io/commits/master

I looked at the README.md for [2], and honestly don’t have a clear idea of 
where to start to submit new content, either basic HTML or HTML plus images. I 
must launch a localhost jekyll server? This looks like a high hurdle. How would 
I contribute content about a specific port?


> On Apr 20, 2021, at 15:03, Rainer Müller  wrote:
> On 20/04/2021 12.40, Steven Smith wrote:
>> That’s begging the question of an effective communications strategy. A 
>> distributed model of random volunteers is perfect for aggregating git 
>> commits. It’s highly ineffective at communicating important news from that 
>> organization.
>> If MacPorts wants to communicate better, it must post important 
>> announcements like “MacPorts supports the new Apple silicon M1” at a 
>> MacPorts website, and someone with a macports.org address must send emails 
>> to a few tech reporters that say “look at this please.”
> 
> If you pledge to handle this kind of marketing, I would have no problem to 
> hand out an @macports.org address for that. By the way, having our own mail 
> domain is not that common for open source projects. Most projects hosted on 
> services such as GitHub/GitLab/etc. will never have that. I really do not 
> think it is of that much significance.
> 
>>> We would be grateful if more users/contributors could join the boat
>>> and actively help in areas where they feel that they could contribute
>>> to the project (in one way or another).
>> That’s precisely why a more effective and realistic commutations strategy is 
>> desirable.
> 
> I don't disagree. But it needs at least one person invested enough to start 
> it and then some more to follow-through with it.
> 
>>> If someone is willing to step up and write blog posts, articles
>>> (potentially based on a few rounds of questions/answers/document
>>> revisions), etc., that would certainly be more than welcome.
>> I’d wager that many people would write these, but the channel and 
>> infrastructure for this do not now exist: no MacPorts News/Announcements 
>> page, no blog page, a somnambulant Twitter feed, 
>> https://twitter.com/macports, and no peer review control mechanism. This can 
>> be accomplished by providing such tools to divide-and-conquer, with an open 
>> peer review mechanism for contributors without commit authority.
> 
> We have the news section on the website [1]. Posts can be submitted with pull 
> requests to the corresponding repository [2]. At the moment, it is only in 
> use for release announcements that are also posted on macports-announce [3]. 
> I don't think anyone would object against posting more.
> 
> I know the Twitter account is not as active as it could be. I personally do 
> not find the time to post there regularly. I can grant you access to the 
> account through TweetDeck if you want to make it more active. There is a list 
> of people with access on the SocialMedia wiki page [4]. Currently the only 
> rule is that tweets should have a signature by their author.
> 
> As you can see, some infrastructure exists. It needs community members to 
> step up and provide content to fill these channels.
> 
> Rainer
> 
> [1] https://www.macports.org/news/
> [2] https://github.com/macports/macports.github.io
> [3] https://lists.macports.org/pipermail/macports-announce/
> [4] 

Re: Publicizing MacPorts

[Andrew Janke]

On 4/19/21 3:54 PM, Craig Treleaven wrote:
>
>> On Apr 19, 2021, at 2:51 PM, Jason Liu > > wrote:
>>
>> On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven > > wrote:
>>
>> Also, why should we consider that MacPorts is in competition with
>> Homebrew?  Both MacPorts and Homebrew seem to have a sufficient
>> number of contributors to keep going for the foreseeable future. 
>> Nether packaging system has to "win" nor does the other have to
>> "lose".  The projects do have differing philosophies that may
>> make one more suitable than the other for particular users.
>>
>>
>> Although this is a nice sentiment, I believe the reality is that
>> MacPorts is in fact in competition with Homebrew. And not just
>> Homebrew, but with other package managers as well, such as Munki, and
>> even to some extent other deployment products such as Jamf/Casper and
>> Jenkins. My belief is that the total number of systems running macOS
>> as its operating system is the entire "pie" of systems that could
>> potentially use one of these macOS package managers. In addition, the
>> vast majority of users will only use one package management product,
>> hence my opinion of why it's a pie with a limited number of potential
>> users that gets divided up. The possible exception to only using one
>> product per machine might be, say, in an enterprise setting (you can
>> read my personal anecdote below for an example).
>>
>> In addition, it has traditionally been the case that package
>> management systems say on their websites that installing multiple
>> package managers on one machine can cause problems... e.g. MacPorts
>> doesn't work well with Fink and Homebrew, Homebrew doesn't work well
>> with Fink and MacPorts, etc. People on this mailing list are tech
>> savvy enough to deal with the potential conflicts that might occur
>> regarding environment variables, $PATH order, etc. but the vast
>> majority of users won't be, and thus would stick to using only one
>> package manager. If one product "wins" by getting installed on a
>> particular system, then the others "lose”.
>>
>
> I wasn’t trying to suggest that a user should install multiple package
> managers.
>
> MacPorts needs contributors and maintainers to go forward.  We don’t
> _need_ users!  It is the same amount of work to create or update a
> package regardless of the number of users.  Several of the packages I
> maintain have very few reported users…sometimes only me.  
>
> As long has we have a decent volume of people contributing to MacPorts
> the project will continue.  As a port maintainer, it is gratifying to
> think that my work may be benefiting others.  It is not that important
> whether it is 10 people or 10,000.  I think that many of our
> maintainers do so because they need the ports that they are working
> on.  IOW, they’d do so even if there were no other users.  Obviously,
> several of our most prolific maintainers have different motivations.
That would be my concern here. Keep the project alive with an active
maintainer community. But I'm a bit different; I want to do work on
projects that are visible and actively helping users; that's (partially)
how I decide where to put my time.
> To be cynical, I think Homebrew users are more commonly command line
> newbies and therefore probably generate a high volume of simple and
> repetitive questions.   AKA ’support desk hell’!  Perhaps we are
> fortunate that MacPorts users tend to be a little more savvy.  ;)
Speaking as a former Homebrew core maintainer – not actually the case!
We got almost no 101-level support requests; Google and StackOverflow
take care of those just fine. The majority of requests coming in to
Homebrew are actually PRs to bump versions on packages (a significant
number of Homebrew users like to be contributors too, and there's almost
a competition to get to new package releases first), and most of the
rest are semi-obscure build and linkage problems, problems with macOS's
System Integrity Protection stuff, or legit workflow issues with the tools.

Though I agree that MacPorts is definitely the "pro" product in this
area, so I expect its users are even more savvy.

Cheers,
Andrew

Re: Publicizing MacPorts

[Rainer Müller]

On 20/04/2021 12.40, Steven Smith wrote:

That’s begging the question of an effective communications strategy. A 
distributed model of random volunteers is perfect for aggregating git commits. 
It’s highly ineffective at communicating important news from that organization.

If MacPorts wants to communicate better, it must post important announcements 
like “MacPorts supports the new Apple silicon M1” at a MacPorts website, and 
someone with a macports.org address must send emails to a few tech reporters 
that say “look at this please.”


If you pledge to handle this kind of marketing, I would have no problem to hand 
out an @macports.org address for that. By the way, having our own mail domain is 
not that common for open source projects. Most projects hosted on services such 
as GitHub/GitLab/etc. will never have that. I really do not think it is of that 
much significance.



We would be grateful if more users/contributors could join the boat
and actively help in areas where they feel that they could contribute
to the project (in one way or another).


That’s precisely why a more effective and realistic commutations strategy is 
desirable.


I don't disagree. But it needs at least one person invested enough to start it 
and then some more to follow-through with it.



If someone is willing to step up and write blog posts, articles
(potentially based on a few rounds of questions/answers/document
revisions), etc., that would certainly be more than welcome.


I’d wager that many people would write these, but the channel and 
infrastructure for this do not now exist: no MacPorts News/Announcements page, 
no blog page, a somnambulant Twitter feed, https://twitter.com/macports, and no 
peer review control mechanism. This can be accomplished by providing such tools 
to divide-and-conquer, with an open peer review mechanism for contributors 
without commit authority.


We have the news section on the website [1]. Posts can be submitted with pull 
requests to the corresponding repository [2]. At the moment, it is only in use 
for release announcements that are also posted on macports-announce [3]. I don't 
think anyone would object against posting more.


I know the Twitter account is not as active as it could be. I personally do not 
find the time to post there regularly. I can grant you access to the account 
through TweetDeck if you want to make it more active. There is a list of people 
with access on the SocialMedia wiki page [4]. Currently the only rule is that 
tweets should have a signature by their author.


As you can see, some infrastructure exists. It needs community members to step 
up and provide content to fill these channels.


Rainer

[1] https://www.macports.org/news/
[2] https://github.com/macports/macports.github.io
[3] https://lists.macports.org/pipermail/macports-announce/
[4] https://trac.macports.org/wiki/SocialMedia

Re: Publicizing MacPorts

[Mojca Miklavec]

On Tue, 20 Apr 2021 at 12:41, Steven Smith wrote:
>
> > What Ryan is trying to say is that "MacPorts" is in fact just a set of
> > random volunteer contributors
>
> That’s begging the question of an effective communications strategy. A 
> distributed model of random volunteers is perfect for aggregating git 
> commits. It’s highly ineffective at communicating important news from that 
> organization.
>
> If MacPorts wants to communicate better, it must post important announcements 
> like “MacPorts supports the new Apple silicon M1” at a MacPorts website, and 
> someone with a macports.org address must send emails to a few tech reporters 
> that say “look at this please.”

I'm not saying that we need 40+ volunteers to write a single paragraph
each, and I don't think that would work well either.

But maybe you (or someone else reading this) would be willing to stand
up and volunteer to organize whatever needs to be done to improve our
communication with the broader community. We probably need just ONE
person with a clear vision, some ideas and a tiny bit of time to boost
the visibility and news from the community.

Would you be willing to lead the effort? I'm sure that others would
gladly help, but it needs to start somewhere and with someone with
sufficient motivation, resources and ideas to carry things out.

Mojca

PS: we have https://www.macports.org/news/, but it's probably not that
helpful. And Clemens is posting news on his personal blog from time to
time. We can certainly improve that if someone willing to write the
contents (with the help of others) shows up.

Re: Publicizing MacPorts

[Steven Smith]

> What Ryan is trying to say is that "MacPorts" is in fact just a set of
> random volunteer contributors

That’s begging the question of an effective communications strategy. A 
distributed model of random volunteers is perfect for aggregating git commits. 
It’s highly ineffective at communicating important news from that organization.

If MacPorts wants to communicate better, it must post important announcements 
like “MacPorts supports the new Apple silicon M1” at a MacPorts website, and 
someone with a macports.org address must send emails to a few tech reporters 
that say “look at this please.”

> We would be grateful if more users/contributors could join the boat
> and actively help in areas where they feel that they could contribute
> to the project (in one way or another).

That’s precisely why a more effective and realistic commutations strategy is 
desirable.

> If someone is willing to step up and write blog posts, articles
> (potentially based on a few rounds of questions/answers/document
> revisions), etc., that would certainly be more than welcome.

I’d wager that many people would write these, but the channel and 
infrastructure for this do not now exist: no MacPorts News/Announcements page, 
no blog page, a somnambulant Twitter feed, https://twitter.com/macports, and no 
peer review control mechanism. This can be accomplished by providing such tools 
to divide-and-conquer, with an open peer review mechanism for contributors 
without commit authority.


> On Apr 20, 2021, at 03:05, Mojca Miklavec  wrote:
> 
> On Mon, 19 Apr 2021 at 15:14, Steven Smith  wrote:
>> 
>>> If you have contacts to tech reporters, please use them. I don't have any. 
>>> If Ars Technica or any other news site wants to cover MacPorts, they can do 
>>> that any time.
>> 
>> This is the wrong attitude.
>> 
>> MacPorts must tell them, not some random user/contributer like me.
> 
> What Ryan is trying to say is that "MacPorts" is in fact just a set of
> random volunteer contributors, each with his/her own talents (and many
> of those without time/motivation to write or without writing skills),
> with a varying level of expertise and available time to devote to the
> project. There is not even any legal entity in the background (there
> probably should be one at some point).
> 
> We would be grateful if more users/contributors could join the boat
> and actively help in areas where they feel that they could contribute
> to the project (in one way or another).
> 
> If you have good ideas about how to improve and promote the project,
> there is no reason why you couldn't take part in the joint effort to
> make the product better in the long run.
> 
> If someone is willing to step up and write blog posts, articles
> (potentially based on a few rounds of questions/answers/document
> revisions), etc., that would certainly be more than welcome.
> 
> Mojca

Re: Publicizing MacPorts

[Mojca Miklavec]

On Mon, 19 Apr 2021 at 15:14, Steven Smith  wrote:
>
> > If you have contacts to tech reporters, please use them. I don't have any. 
> > If Ars Technica or any other news site wants to cover MacPorts, they can do 
> > that any time.
>
> This is the wrong attitude.
>
> MacPorts must tell them, not some random user/contributer like me.

What Ryan is trying to say is that "MacPorts" is in fact just a set of
random volunteer contributors, each with his/her own talents (and many
of those without time/motivation to write or without writing skills),
with a varying level of expertise and available time to devote to the
project. There is not even any legal entity in the background (there
probably should be one at some point).

We would be grateful if more users/contributors could join the boat
and actively help in areas where they feel that they could contribute
to the project (in one way or another).

If you have good ideas about how to improve and promote the project,
there is no reason why you couldn't take part in the joint effort to
make the product better in the long run.

If someone is willing to step up and write blog posts, articles
(potentially based on a few rounds of questions/answers/document
revisions), etc., that would certainly be more than welcome.

Mojca

Re: Publicizing MacPorts

[Georges Martin]

Done: https://github.com/macports/macports-ports/pull/10726

> Le 19 avr. 2021 à 23:46, Clemens Lang  a écrit :
> 
> Hi,
> 
> On Mon, Apr 19, 2021 at 07:58:02PM +0200, Georges Martin wrote:
>> Speaking of the PR checklist, the "Tested On" section could include the 
>> architecture name:
>> 
>>  echo "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion) on 
>> $(uname -m)"
>> 
>> As I'm now testing both on x86_64 and arm64, that's something I try to 
>> include in my PRs...
> 
> Very nice idea. See
> https://github.com/macports/macports-ports/blob/master/.github/PULL_REQUEST_TEMPLATE.md,
> which contains this. Could you submit a PR for the change?
> 
> -- 
> Clemens

Re: Publicizing MacPorts

[Clemens Lang]

Hi,

On Mon, Apr 19, 2021 at 07:58:02PM +0200, Georges Martin wrote:
> Speaking of the PR checklist, the "Tested On" section could include the 
> architecture name:
> 
>   echo "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion) on 
> $(uname -m)"
> 
> As I'm now testing both on x86_64 and arm64, that's something I try to 
> include in my PRs...

Very nice idea. See
https://github.com/macports/macports-ports/blob/master/.github/PULL_REQUEST_TEMPLATE.md,
which contains this. Could you submit a PR for the change?

-- 
Clemens

Re: Publicizing MacPorts

[Craig Treleaven]

> On Apr 19, 2021, at 2:51 PM, Jason Liu  wrote:
> 
> On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven  > wrote:
> Also, why should we consider that MacPorts is in competition with Homebrew?  
> Both MacPorts and Homebrew seem to have a sufficient number of contributors 
> to keep going for the foreseeable future.  Nether packaging system has to 
> "win" nor does the other have to "lose".  The projects do have differing 
> philosophies that may make one more suitable than the other for particular 
> users.
> 
> Although this is a nice sentiment, I believe the reality is that MacPorts is 
> in fact in competition with Homebrew. And not just Homebrew, but with other 
> package managers as well, such as Munki, and even to some extent other 
> deployment products such as Jamf/Casper and Jenkins. My belief is that the 
> total number of systems running macOS as its operating system is the entire 
> "pie" of systems that could potentially use one of these macOS package 
> managers. In addition, the vast majority of users will only use one package 
> management product, hence my opinion of why it's a pie with a limited number 
> of potential users that gets divided up. The possible exception to only using 
> one product per machine might be, say, in an enterprise setting (you can read 
> my personal anecdote below for an example).
> 
> In addition, it has traditionally been the case that package management 
> systems say on their websites that installing multiple package managers on 
> one machine can cause problems... e.g. MacPorts doesn't work well with Fink 
> and Homebrew, Homebrew doesn't work well with Fink and MacPorts, etc. People 
> on this mailing list are tech savvy enough to deal with the potential 
> conflicts that might occur regarding environment variables, $PATH order, etc. 
> but the vast majority of users won't be, and thus would stick to using only 
> one package manager. If one product "wins" by getting installed on a 
> particular system, then the others "lose”.
> 


I wasn’t trying to suggest that a user should install multiple package managers.

MacPorts needs contributors and maintainers to go forward.  We don’t _need_ 
users!  It is the same amount of work to create or update a package regardless 
of the number of users.  Several of the packages I maintain have very few 
reported users…sometimes only me.  

As long has we have a decent volume of people contributing to MacPorts the 
project will continue.  As a port maintainer, it is gratifying to think that my 
work may be benefiting others.  It is not that important whether it is 10 
people or 10,000.  I think that many of our maintainers do so because they need 
the ports that they are working on.  IOW, they’d do so even if there were no 
other users.  Obviously, several of our most prolific maintainers have 
different motivations.

To be cynical, I think Homebrew users are more commonly command line newbies 
and therefore probably generate a high volume of simple and repetitive 
questions.   AKA ’support desk hell’!  Perhaps we are fortunate that MacPorts 
users tend to be a little more savvy.  ;)

Craig

Re: Publicizing MacPorts

[Jason Liu]

On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven 
wrote:

> Also, why should we consider that MacPorts is in competition with
> Homebrew?  Both MacPorts and Homebrew seem to have a sufficient number of
> contributors to keep going for the foreseeable future.  Nether packaging
> system has to "win" nor does the other have to "lose".  The projects do
> have differing philosophies that may make one more suitable than the other
> for particular users.
>

Although this is a nice sentiment, I believe the reality is that MacPorts
is in fact in competition with Homebrew. And not just Homebrew, but with
other package managers as well, such as Munki, and even to some extent
other deployment products such as Jamf/Casper and Jenkins. My belief is
that the total number of systems running macOS as its operating system is
the entire "pie" of systems that could potentially use one of these macOS
package managers. In addition, the vast majority of users will only use one
package management product, hence my opinion of why it's a pie with a
limited number of potential users that gets divided up. The possible
exception to only using one product per machine might be, say, in an
enterprise setting (you can read my personal anecdote below for an example).

In addition, it has traditionally been the case that package management
systems say on their websites that installing multiple package managers on
one machine can cause problems... e.g. MacPorts doesn't work well with Fink
and Homebrew, Homebrew doesn't work well with Fink and MacPorts, etc.
People on this mailing list are tech savvy enough to deal with the
potential conflicts that might occur regarding environment variables, $PATH
order, etc. but the vast majority of users won't be, and thus would stick
to using only one package manager. If one product "wins" by getting
installed on a particular system, then the others "lose".



Personal Anecdote

In one of my former lives, I used to work as a systems administrator for
one of the science departments at a local university, and we used more than
one package management system (PMS) on our Macs. The central,
university-wide IT support group used a combination of Munki and Jenkins to
deploy proprietary commercial software that requires license keys, such as
Adobe and Microsoft products. The department-level IT support staff have
superuser access on each of the computers, but we didn't have the ability
to contribute our own software packages to the central IT's Munki/Jenkins
servers. So, several science departments banded together to also deploy
MacPorts on their departments' Macs, so that we could manage software
packages that were of interest to the individual departments. We were also
aware of other departments that used Homebrew as their departmental PMS. In
fact, the central IT group even added a Homebrew "installer" to the list of
software available through Munki, but refused to add the MacPorts installer
(the sysadmin that was the head of managing the Munki servers loved
Homebrew and Ruby, and absolutely hated Tcl).

This is one of the few instances where I could see the benefit of having
more than one PMS installed on the same machine. But for home computers
that are being managed by a single family member, or even computers
(laptops) that are only ever used by a single person, I highly doubt that
they would willingly go through the hassle of obtaining their software
through more than one PMS.

-- 
Jason Liu


On Mon, Apr 19, 2021 at 1:25 PM Craig Treleaven 
wrote:

> > On Apr 19, 2021, at 10:47 AM, Karl-Michael Schindler <
> karl-michael.schind...@physik.uni-halle.de> wrote:
> >
> > Am 19.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
> >>
> >> Date: Mon, 19 Apr 2021 13:24:51 +0200
> >> From: Mojca Miklavec 
> >> Subject: Re: Publicizing MacPorts
> >> Message-ID: <
> calbomsbrso9ao2sgvonvp69hskephjiwzhscmwmi_f6cfay...@mail.gmail.com>
> >> Content-Type: text/plain; charset="UTF-8"
> >>
> >> We should probably be publicising that MacPorts works just fine with
> >> M1 more aggressively from the very beginning.
> >>
> >> If anyone is willing to volunteer to do PR for MacPorts ...
> >>
> >> Mojca
> >
> > I intend to do so, probably to a limited extend only. As a first step, I
> have checked the upstream download pages of our top ten downloads. Less
> than 5 of them mention macports properly. My next steps is to write to
> them. I also want to extent the maintainer part of the docs with the direct
> to port maintainer to check upstream download and install pages.
> >
> > Michael.
>
> People don’t install MacPorts or Homebrew just to have a package
> manager—they install a package manager as a prerequisi

Re: Publicizing MacPorts

[Dave Allured - NOAA Affiliate via macports-dev]

It would be very helpful for new impressions of Macports, if the ports
website could be fixed to properly show current port status.  This problem
has been lingering for months now:

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


On Mon, Apr 19, 2021 at 9:59 AM Dave Allured - NOAA Affiliate <
dave.allu...@noaa.gov> wrote:

> Here are a few ideas.  How many M1 ports are working on Macports?  How
> many on Homebrew and other competitors?
>
> How long ago did Macports start to have working M1 ports?
>
> Are there any noteworthy M1 ports that are working on Macports, but not on
> Homebrew?
>
>
> On Mon, Apr 19, 2021 at 8:47 AM Rainer Müller  wrote:
>
>>
>> So, if MacPorts were to make an announcement now, what would you put in
>> there?
>> Can you show us a draft? "MacPorts works like it always has" is barely
>> newsworthy.
>>
>

Re: Publicizing MacPorts

[Craig Treleaven]

> On Apr 19, 2021, at 10:47 AM, Karl-Michael Schindler 
>  wrote:
> 
> Am 19.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
>> 
>> Date: Mon, 19 Apr 2021 13:24:51 +0200
>> From: Mojca Miklavec 
>> Subject: Re: Publicizing MacPorts
>> Message-ID: 
>> 
>> Content-Type: text/plain; charset="UTF-8"
>> 
>> We should probably be publicising that MacPorts works just fine with
>> M1 more aggressively from the very beginning.
>> 
>> If anyone is willing to volunteer to do PR for MacPorts ...
>> 
>> Mojca
> 
> I intend to do so, probably to a limited extend only. As a first step, I have 
> checked the upstream download pages of our top ten downloads. Less than 5 of 
> them mention macports properly. My next steps is to write to them. I also 
> want to extent the maintainer part of the docs with the direct to port 
> maintainer to check upstream download and install pages.
> 
> Michael.

People don’t install MacPorts or Homebrew just to have a package manager—they 
install a package manager as a prerequisite to get software that they want.  So 
getting popular software packages to mention that MacPorts can install that 
software is very important.  

Also, why should we consider that MacPorts is in competition with Homebrew?  
Both MacPorts and Homebrew seem to have a sufficient number of contributors to 
keep going for the foreseeable future.  Nether packaging system has to “win” 
nor does the other have to "lose”.  The projects do have differing philosophies 
that may make one more suitable than the other for particular users.  For 
example, Homebrew only aims to support recent hardware and up-to-date operating 
system versions even if users are sometimes left behind.  MacPorts makes far 
greater efforts to ensure packages work on older hardware and OS versions.  We 
might do a better job of explaining how MacPorts differs so that users can make 
an informed choice.

My $0.02 (and Canada doesn’t even have pennies anymore!).

Craig

Re: Publicizing MacPorts

[Dave Allured - NOAA Affiliate via macports-dev]

Here are a few ideas.  How many M1 ports are working on Macports?  How many
on Homebrew and other competitors?

How long ago did Macports start to have working M1 ports?

Are there any noteworthy M1 ports that are working on Macports, but not on
Homebrew?


On Mon, Apr 19, 2021 at 8:47 AM Rainer Müller  wrote:

>
> So, if MacPorts were to make an announcement now, what would you put in
> there?
> Can you show us a draft? "MacPorts works like it always has" is barely
> newsworthy.
>

Re: Publicizing MacPorts

[Karl-Michael Schindler]

Am 19.04.2021 um 14:00 schrieb macports-dev-requ...@lists.macports.org:
> 
> Date: Mon, 19 Apr 2021 13:24:51 +0200
> From: Mojca Miklavec 
> Subject: Re: Publicizing MacPorts
> Message-ID: 
> 
> Content-Type: text/plain; charset="UTF-8"
> 
> We should probably be publicising that MacPorts works just fine with
> M1 more aggressively from the very beginning.
> 
> If anyone is willing to volunteer to do PR for MacPorts ...
> 
> Mojca

I intend to do so, probably to a limited extend only. As a first step, I have 
checked the upstream download pages of our top ten downloads. Less than 5 of 
them mention macports properly. My next steps is to write to them. I also want 
to extent the maintainer part of the docs with the direct to port maintainer to 
check upstream download and install pages.

Michael.

Re: Publicizing MacPorts

[Rainer Müller]

On 19/04/2021 15.14, Steven Smith wrote:

If you have contacts to tech reporters, please use them. I don't have any. If 
Ars Technica or any other news site wants to cover MacPorts, they can do that 
any time.


This is the wrong attitude.

MacPorts must tell them, not some random user/contributer like me.


In my opinion, users have to spread the word to make MacPorts more popular.


And the press likely won’t think an issue is important or interesting enough to 
cover if the related organization doesn’t think it’s interesting enough to post 
an announcement about it.


They are much more likely to post an article if they know users will be 
interested in it.


So, if MacPorts were to make an announcement now, what would you put in there? 
Can you show us a draft? "MacPorts works like it always has" is barely newsworthy.


Rainer

Re: Publicizing MacPorts

[Steven Smith]

> If you have contacts to tech reporters, please use them. I don't have any. If 
> Ars Technica or any other news site wants to cover MacPorts, they can do that 
> any time.

This is the wrong attitude. 

MacPorts must tell them, not some random user/contributer like me.

Everyone has tech reporter contacts: their email and Twitter handle and contact 
info is all posted online with every article.

And the press likely won’t think an issue is important or interesting enough to 
cover if the related organization doesn’t think it’s interesting enough to post 
an announcement about it. 


> On Apr 19, 2021, at 07:48, Rainer Müller  wrote:
> 
> If you have contacts to tech reporters, please use them. I don't have any. If 
> Ars Technica or any other news site wants to cover MacPorts, they can do that 
> any time.

Re: Publicizing MacPorts

[Steven Smith]

> We never made any announcement since it basically "worked from day 1"


Then that’s the announcement!

No one will know this stuff if MacPorts doesn’t tell them.

There must be one or two regular broadcast channels: perhaps a blog on your 
website for major announcer, and Twitter feed for regular highlighted items of 
interest, perhaps featured upgrades or MacPorts-specific ports and news.


> On Apr 19, 2021, at 07:25, Mojca Miklavec  wrote:
> 
> We never made any announcement since it basically "worked from day 1"

Re: Publicizing MacPorts

[Rainer Müller]

On 19/04/2021 12.45, Steven Smith wrote:

"Champion" how?

"MacPorts should be making [the case]" how?


The same way everyone else does: make noise, push news, promote, let the tech 
reporters know. Follow the Woody Allen rule for success.


If a comparable announcement to this was made for MacPorts, I missed it:

https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/ 



If you have contacts to tech reporters, please use them. I don't have any. If 
Ars Technica or any other news site wants to cover MacPorts, they can do that 
any time.


Maybe we could sent out news to macports-announce about support of new macOS 
releases as well as the arm64 architecture. But at which point would you do it? 
There are continuously updated ports with support or fixes for arm64. The 
announcement for 2.6.4 in November [1] briefly mentioned the support for arm64. 
But I don't know what more to say, because... it just works? ;-)


MacPorts 2.0 that introduced binary archives also got news coverage, which was 
mostly because we increased the major version number. Homebrew did the same 
thing now, because they had to make changes to support an additional 
architecture, thus they got the news coverage. MacPorts did not need that many 
changes to support arm64, because it had the general support for multiple 
architectures already.


Rainer

[1] 
https://lists.macports.org/pipermail/macports-announce/2020-November/57.html

Re: Publicizing MacPorts

[Mojca Miklavec]

On Mon, 19 Apr 2021 at 12:45, Steven Smith wrote:
>
> If a comparable announcement to this was made for MacPorts, I missed it:
>
> https://arstechnica.com/gadgets/2021/02/mac-utility-homebrew-finally-gets-native-apple-silicon-and-m1-support/

We never made any announcement since it basically "worked from day 1"
(almost), and we never had any specific point in time when support for
M1 was significantly improved. (We probably needed an upgrade of
MacPorts base, but that happened very soon.)

We should probably be publicising that MacPorts works just fine with
M1 more aggressively from the very beginning.

If anyone is willing to volunteer to do PR for MacPorts ...

Mojca

Re: Publicizing MacPorts

[Ryan Schmidt]

On Apr 18, 2021, at 07:28, Steven Smith wrote:

>>> I completely agree that Homebrew is currently winning at publicity.
>> 
>> What should the MacPorts community be doing do publicize MacPorts better?
> 
> The new M1 architecture is a perfect opportunity to champion MacPorts’s 
> strengths:
> 
> • Strong emphasis on binaries built from source code, often specifically 
> patched
> • Strong emphasis on smart, solid engineering with high quality, reliable 
> installs
> • Extraordinarily comprehensive coverage across both software and 
> architectures
> • Expert, engaged, and helpful development community
> 
> We’re seeing all these strengths play out in MacPorts’s successful and 
> ongoing migration to the new M1 chip.
> 
> We’re also seeing the contrast of how Homebrew’s undesirable design 
> decisions, reliance on external binaries, and other shortcuts affect its 
> migration to the M1: https://github.com/Homebrew/brew/issues/7857
> 
> This is an easy case to make, and MacPorts should be making it, using the M1 
> as a banner example.

Sure.

"Champion" how?

"MacPorts should be making [the case]" how?

I know our main web site needs an overhaul, and drawing attention to some of 
these facts there would be good. In what other ways, what other venues, do you 
envision this information being communicated?

Publicizing MacPorts

[Steven Smith]

>> I completely agree that Homebrew is currently winning at publicity.
> 
> What should the MacPorts community be doing do publicize MacPorts better?

The new M1 architecture is a perfect opportunity to champion MacPorts’s 
strengths:

• Strong emphasis on binaries built from source code, often specifically patched
• Strong emphasis on smart, solid engineering with high quality, reliable 
installs
• Extraordinarily comprehensive coverage across both software and architectures
• Expert, engaged, and helpful development community

We’re seeing all these strengths play out in MacPorts’s successful and ongoing 
migration to the new M1 chip.

We’re also seeing the contrast of how Homebrew’s undesirable design decisions, 
reliance on external binaries, and other shortcuts affect its migration to the 
M1: https://github.com/Homebrew/brew/issues/7857

This is an easy case to make, and MacPorts should be making it, using the M1 as 
a banner example.