MacPorts Status

[Ryan Schmidt]

On Jun 11, 2022, at 09:07, Jordan wrote:

> 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 am starting to spin up maintaining a few ports after a long break from macOS (mostly because until M1 machines came around the hardware sucked if I am honest).

Welcome!


> 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?

It is true that there have always been many more things that could be done to improve MacPorts than there are people available to do those things.

But I am not certain what specifically you're referring to here. There are dozens of commits to MacPorts each day, several tickets filed each day, frequent discussions occur on the mailing lists. What do you perceive to be neglected?


> Things like the timeline on Trac are years old,

I'm not sure what timeline you're referring to. I see there is a Timeline button on the Trac toolbar, which I think I have probably never used before today, but clicking it now, it appears to be up to date with the latest changes from today:

https://trac.macports.org/timeline


> the use of `sudo` by default probably scares new users etc etc.

The use of sudo increases security and protects the user from potentially malicious changes to their files. I am not aware that the use of sudo scares new users, but if it does, then improved education of new users is the solution.


> I'm looking to contribute to some kind of effort to "modernise" (again, for lack of a better word) MacPorts so perhaps some usage compared to things like Homebrew can be gained back since I'd love to see this project used more.

Since most of us are not familiar with Homebrew, perhaps you could describe exactly what aspects of it you'd like to see adopted by MacPorts. But of course Homebrew and MacPorts are different projects with different goals written in different programming languages by different people so while we may borrow ideas from one another here and there they probably won't become very similar.

I'm all for making MacPorts easier to use, and there have been countless previous threads on the mailing list discussing ways to do that. But of course as with any volunteer-based open-source project, nothing actually gets done until somebody volunteers to do it, where "do it" includes writing the code, yes, but for significant or potentially controversial changes you probably want to have a discussion on the mailing list first to gain consensus that your proposed change should be made, to save you the time of writing code if that code is implementing something that wouldn't be accepted anyway.


> Also, as a tacked-on issue I am working on packaging a port and MacPorts is smart enough to only remove the files within directories as present when the port was imaged but I was hoping for a cheeky setting to change this so that it "dumb"ly deletes the entire folder.
> 
> For example, the port is imaged and at the time of imaging has a `${prefix}/lib/foo/bar` directory with a single file in it. If I immediately uninstall the port then `bar` is correctly deleted since it is _exactly_ as it was when the port was installed from its image. However, if I add files to `bar` then MacPorts only removes those that single file that is part of the port image, leaves the others alone, and because `bar` is now not-empty leaves `bar`. I wonder if I can force MacPorts to always delete `bar`?

When a port is installed, only the files that it installs are tracked in the registry. Directories themselves are not tracked. When deactivating a port, if no files are left in a directory, the directory is deleted, otherwise it is kept.

You can write pre- and post- activate and deactivate blocks to do any additional tasks before or after MacPorts activates or deactivates a port. For example, there are several font ports that update the fontconfig cache after activation. It is not normal for a port to delete files it didn't install, but it is possible to program the port to do that, and I could imagine some use cases for that. Carefully consider whether that is the right thing to do. What are these files that you are deleting? Consider that when a user upgrades a port, that includes deactivating the old version of the port and activating the new version. Will the new version want to have those files you're deleting? Where did the files come from? Did the user create them? If so, the user may not expect MacPorts to delete them.