Add a field to port information that specifies whether that port is distributed as a binary or requires a lengthy rebuild

[esbugz]

I thought that port details with various OS versions, for example, ​https://ports.macports.org/port/gocryptfs/details/, imply that there is a prebuilt package for a green-check-marked system

But it's not the case, so I'd like to suggest adding such information to the details page and the info commands as it makes a big difference in installation time & space requirements

[ryandesign (Ryan Carsten Schmidt)]

ports.macports.org tells you whether a build of a port has been attempted, and if so what the result of that build was, but it does not tell you whether the package that resulted from a successful build was uploaded to the public server.

In the case of gocryptfs, we do not distribute a prebuilt package because we believe we are not legally permitted to do so due to the combination of its license and the licenses of its dependencies.

% ./port_binary_distributable.tcl -v gocryptfs
"gocryptfs" is not distributable because its dependency "macfuse" has license "restrictive" which is not known to be distributable

[esbugz]

Ok, thanks for the clarification! Is there a more accessible place to get this basic port info? At least the details page could maybe include it, though would also be nice to know from the info command?

P.S. changed this from a port bug to a general enhancement

[ryandesign (Ryan Carsten Schmidt)]

Determining whether a port can be distributed as a binary could be determined offline and added to port info after #60315 is implemented.

Determining whether a port is available as a binary would require performing an http(s) request to the packages server.

[esbugz]

Replying to ryandesign:

Determining whether a port is available as a binary would require performing an http(s) request to the packages server.

Why couldn't it be stored in the local database not introduce this request delay?

[ryandesign (Ryan Carsten Schmidt)]

Any locally-stored information would be out-of-date. A binary could have been produced on the build servers between the time that your local database was updated and the time that you asked whether a binary archive of a port was available. Also, there is no local database. And if one were to be created for this purpose, there is no server-side source of information from which that database could be populated.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

there is no local database.

There is the PortIndex, which is where port info gets its information. The PortIndex is generated by parsing the Portfiles. Most users receive a PortIndex that was created on our servers. Entries in the PortIndex are only updated when the portindex command is run and only if the corresponding Portfile has changed on disk.

[ryandesign (Ryan Carsten Schmidt)]

Replying to esbugz:

stored in the local database

If you were referring to the ports.macports.org web site, then yes, I believe it does have a database that is populated by first updating the PortIndex and then parsing it somehow. The web site also contains information that didn't come from the PortIndex, like livecheck information; the web site periodically runs port livecheck on every port (performing an http(s) request for each one) to update that information. Yes, presumably a similar process could be used to perform http(s) requests for each port for each OS version and architecture, periodically, to see if a binary archive exists on the server. (Bear in mind that there are currently 30,000 ports ⨉ 21 OS version/architecture combinations on which MacPorts works, so that would be a lot of http(s) requests.) If you would like to suggest that as a feature request for the ports.macports.org web site, that would be handled at ​https://github.com/macports/macports-webapp/issues.

[esbugz]

Replying to ryandesign:

Any locally-stored information would be out-of-date. A binary could have been produced on the build servers between the time that your local database was updated and the time that you asked whether a binary archive of a port was available.

Nothing selfupdate couldn't fix

And if one were to be created for this purpose, there is no server-side source of information from which that database could be populated.

??? The list of prebuilt binaries located on the server is the source of information

Most users receive a PortIndex that was created on our servers.

Exactly, and your servers have information about what prebuilt binaries they host, so they can add that information to the index synced with the users' machines

Yes, presumably a similar process could be used to perform http(s) requests for each port for each OS version and architecture, periodically, to see if a binary archive exists on the server

Why would you need to a gazillion of individual http requests instead of:

• (full rebuild) simply making the server produce a recursive list of all the prebuilt binaries it hosts, and then refreshing the database
• on every upload/removal of a prebuilt binary to the server you could get this log info and similarly update the database