Re: End of Python 2.4–2.6 and 3.1–3.3 support
ryandesign at macports.org
Sat Oct 11 06:31:20 PDT 2014
On Oct 11, 2014, at 8:07 AM, René J.V. Bertin wrote:
> On Saturday October 11 2014 07:40:16 Ryan Schmidt wrote:
>> If a port depends on p5.12-X but p5.16-X would work, the port should update its dependency. 5.16 is the default version of perl in MacPorts at this time which all ports that require perl functionality should use, unless other versions are needed for special reasons.
> There's no way to just depend on p5-X and let the port framework translate that to the default perl version? (Idem for python, ruby, etc...)
Right, ports should not depend on p5-X ports. Instead, depend on the specific p5.??-X the port is going to use. The specific version of perl being used often gets baked into the files that get installed, therefore it's important that the dependency reflects that.
>> If needed, use "sudo port setrequested" or "sudo port unsetrequested" to fix the above lists.
> I presume that ports that get installed by the user (and not by following a dependency) already are requested...
>> Then you can clean up by running "sudo port uninstall inactive and unrequested".
> Ah! That's the 1st time I see that one can combine filters like that, it seems indeed that this would go in the right direction. It still doesn't allow to discriminate between 2 inactive ports that were both installed at explicit request. Apt's "hold" does that, it signals that a held package should never be touched, not for upgrading and not for automatic uninstalling (if it's an "automatic" (= unrequested) package).
Yeah you're right, "sudo port uninstall inactive and unrequested" doesn't quite do what you want, since it wouldn't uninstall inactive (i.e. prior) versions of ports you did request.
We do have the new reclaim command that was implemented during this year's Google Summer of Code; perhaps that helps.
(I wish this information was linked from the main MacPorts GSoC page...)
More information about the macports-users