On Mar 10, 2016, at 2:15 PM, Daniel J. Luke <dl...@geeklair.net> wrote:
> On Mar 10, 2016, at 2:05 PM, Ryan Schmidt <ryandes...@macports.org> wrote: >>> That's probably safe, but I don't think there is a compelling reason to try >>> and only revbump the minimal set of ports (better to have some needless >>> rebuilds/downloads of binary archives than to have mysteriously broken >>> ports). >> >> You can't programmatically revbump safely, > > with existing tool(s). > >> because in ports with subports you have to manually determine which >> subport(s) to revbump and how to do so. > > 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, but I'm not sure how to programmatically understand the coding style of a given portfile. >> 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. 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. >> So if you're manually examining all ports that depend on openssl, you can >> run an "svn log" on them to see if any commits after r146162 updated the >> version or revision. > > ick. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
