That's what I said, no coherence or coordination. So what are your reasons to not use HomeBrew?
On Sat, Jun 11, 2022, 22:40 Jim DeLaHunt <list+macports-...@jdlh.com> wrote: > Hello, Jordan: > > Welcome (back to) MacPorts! > > I am nobody official with the project. I just try to make contributions > to a few ports and documentation pages where I can. But in this project, > lots of people contribute, each in their own way. > > On 2022-06-11 07:07, Jordan via macports-dev wrote: > > Hi friends, > > > > > > First of all thank you for your work! I use MacPorts exclusively for a > > few different reasons and am looking to contribute to the project.... > > I for one would be glad to have your contributions. > > > There is one aspect of MacPorts that has me a little down in the dumps > > and that's is its _apparent_ (but likely not true) neglected state. I > > think it's perhaps under maintained currently due to a lack of > > people-power? I say so because I'd love to see more people using > > MacPorts so I wonder if there's any "modernisation" (for lack of a > > better word) to be had here? ... so perhaps some usage compared to > > things like Homebrew can be gained back since I'd love to see this > > project used more. > > I think it is not fair to say MacPorts overall is in a neglected state. > Its core purpose is to help people compile a wide range of freely > available software on the macOS platform. As part of that it helps > gather the related software needed to make the requested software work. > I think that this aspect of MacPorts works very well. It gets a lot of > care and attention. There is a lot of activity. For instance, I just > moved onto an M1 Mac, and I see a lot of support for compiling software > with the M1 CPU's architecture. That is the opposite of neglect. > > Now, certain aspects of the project are neglected. You mention the > timeline on Trac. That's a page of documentation. > > When you say "modernisation", I think you mean, changes to how MacPorts > work to make it easier or better for some audience. I think that is best > approached as a collection of small projects, each with a specific > understanding of a problem, and its own goal for an improvement. One way > to proceed is to start a macPorts-dev thread for each of these ideas > (and each with a different Subject: line, please). > > You mention believing that `sudo` probably scares new users. Maybe so, > maybe not. A first step is to gather some evidence whether this is true. > A next step is to figure out why the port tool requires use of `sudo`. A > third step is to figure out what alternative way the port tool could > work which does not require `sudo`. For my part, use of `sudo` is no > problem at all. MacPorts is a command-line tool for system maintenance. > I am used to system maintenance tools requiring administrator passwords. > `sudo` is a command-line way of requiring a password. > > I will also say that competing with Homebrew about which project has > more users is not very interesting to me. Homebrew works well for some > people. MacPorts works well for some people. I'm interested in helping > MacPorts be the best MacPorts it can be. If Homebrew ends up with more > users, that is no big deal to me. > > > Also, as a tacked-on issue I am working on... > > I suggest you start a separate email thread for each issue. If you try > to discuss deleting files on uninstall as part of a thread with the > Subject: of "MacPorts status", which was originally about your offer to > help, I suspect you will lose a lot of readers. > > Anyhow, I look forward to seeing you in the email list, and in the trac > tickets, and in the Pull Requests! Glad to have your help. > > Best regards, > —-Jim "just another MacPorts user/contributor" DeLaHunt > >
