Apache2 rev bump for OpenSSL update

Daniel J. Luke dluke at geeklair.net
Thu Mar 10 12:27:05 PST 2016

On Mar 10, 2016, at 3:18 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>> The general problem is something we should address.
>> (a 'compatibility version' we store for ports and make part of the dependency engine? a better 'revbump a bunch of ports tool'? something else?)
>> We should have a way to reliably force rebuilds
> We do: increase the revision.
> If you mean we should have a reliable way to programmatically increase the revision of a port, maybe,

reliably programmatically increasing the revision is one possible solution to the actual problem (which is "I need to force any ports that depend on my port to rebuild.")

Today, we do that by increasing the revision of all affected ports (manually, or with some help from a script).

> but I'm not sure how to programmatically understand the coding style of a given portfile.

It's possible (we load and execute portfiles today).

It would probably be easier if portfiles more consistently kept to key/value style (or if we didn't use tcl as our parser).

>>> e.g. the php port is definitely a special case.
>> (and is otherwise problematic since it has us distributing versions of php that no longer have upstream support)
> I don't consider that a problem.

distributing software that has known security bugs is a problem.

> The php web site also still distributes versions of php that they no longer support. In any case it does not relate to the discussion at hand.

http://php.net/downloads.php lists 7.0.4, 5.6.19, and 5.5.33 (older releases are still there, but with the disclaimer "listed for archival purposes only").

We can split the thread if you want to discuss further. You're right that it's only tangentially related (the port would be less complicated if it didn't have to support as many php versions).

Daniel J. Luke

More information about the macports-dev mailing list