On Mar 10, 2016, at 2:27 PM, Daniel J. Luke <[email protected]> wrote: > > On Mar 10, 2016, at 3:18 PM, Ryan Schmidt <[email protected]> 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).
I don't see how we could possibly change away from tcl at this point. If we balk at manually examining 300 portfiles to see if they're already been revbumped for the openssl update, nobody is going to manually examine 10,000 portfiles to make them conform to a different 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. We'll have to agree to disagree. The unsupported php ports print a message that they're unsupported. Someone installing an old php port despite those messages must really want that version, for example in order to test and perhaps update an old web site designed with that version. Removing the old php subports from MacPorts just wastes the user's time as the user is forced to manually locate and figure out how to patch and compile the old version. >> 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"). http://museum.php.net > 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). Not substantially. Most of the complexity comes from supporting more than one version. Supporting more than two versions is no more difficult. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
