[MacPorts] #51664: Please add pseudo-portnames for some common programs

Rainer Müller raimue at macports.org
Thu Jun 30 05:25:24 PDT 2016

On 2016-06-29 19:39, Jeffrey Walton wrote:
>>  The `--long_description` modifier is just the field as written in the
>>  Portfile.
>>  Regarding searching for binaries in ports, this is a completely different
>>  problem that would be addressed by having an offline index of port
>>  contents for uninstalled ports.
>>  As this ticket does not propose any solution, I am closing this. Please
>>  start discussion on the [MailingLists macports-dev] mailing list. Only
>>  after having a plan, a ticket should be created with the outcome of the
>>  discussion to track the progress of the implementation.
> You know there is a chronic problem; and you have proposed solution.

What is the solution? Sorry if I do not understand it yet, but how do
you propose it should be implemented?

What I understood from the ticket is that you proposed to make the
command 'sudo port install <binaryname>' install the port that contains
a binary by this name. That would still not be enough to implement this.
Is that just any file in a a port at ${prefix}/bin? What if there are
multiple candidates?

At the moment, we do not have any database for this kind of mapping.
There also was another recent thread discussing that no such database

Even with that, the proposal would not work for everything. There is no
port that provides a 'python' binary. The GNU coreutils are provided
with a 'g' prefix, in order not to override standard system utils by
default. Searching for the binary name here will not return any results.

The ticket then went on about searching for ports. Just including the
name of the binaries into the description of ports would be a task that
can be done individually. You are welcome to file tickets to the port
maintainers suggesting to add that. Even better, attach a patch that
directly implements this change to the description.

> Its your sandbox. Feel free to do nothing so it does not work as
> expected in the future.

Please do not misunderstand this. I am open to change everything,
keeping corner cases and backwards compatibility in mind.

I suggested to discuss this at the mailing list, where it gets more
visibility. The tickets are helpful to keep progress when implementing
new features for base, but are not a good place for discussions.


More information about the macports-dev mailing list