Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?

[Joshua Root]

Richard L. Hamilton  wrote:

>/On Jan 22, 2022, at 11:13, Ryan Schmidt > wrote: />//>/Release date information is not available in MacPorts. Are you 
proposing that the maintainer of every port should do research to 
discover the release date every time they want to update a port to a 
new version and add that information to a new field in the portfile? Why? />//>/Or are you referring to the date when an update of a portfile was 
committed to GitHub? If so, why would that be useful to you? /

The latter, since the former, although possibly more useful, is too difficult.


That part at least is simple:

ls -l `port file someport`

- Josh

Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?

[Marius Schamschula]

On Jan 24, 2022, at 3:33 PM, Ryan Schmidt  wrote:
> 
>> A possible alternative: a reasonably easy way to keep only the most recent X 
>> inactive versions of a port with a given set of variants. That way one could 
>> keep things reasonably clean but have something to fall back to. If there's 
>> a non-manual way to do that (short of a creative script that digests the 
>> output of "port installed"), I must have missed it.
> 
> There isn't anything built-in to do that. It could be scripted, as you 
> suggest. "port reclaim" deletes all inactive ports, I believe. It wouldn't be 
> unreasonable to enhance it with the ability to keep the n most recent 
> versions of each port.

I have a simple shell script, mptidy, that keeps the two most recent versions 
of a port.

It allows me to reactivate the old version if there is an issue with a new 
build.

However, it isn’t smart enough to deal with multiple variant builds, etc.

Marius
--
Marius Schamschula

Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?

[Ryan Schmidt]

On Jan 22, 2022, at 10:21, Richard L. Hamilton wrote:

> On Jan 22, 2022, at 11:13, Ryan Schmidt wrote:
> 
>> Or are you referring to the date when an update of a portfile was committed 
>> to GitHub? If so, why would that be useful to you?
> 
> The latter, since the former, although possibly more useful, is too difficult.
> 
> Ideally, one has active the latest available version of a port, esp. given 
> dependencies. But that doesn't always build, nor even always fail on first 
> use after being built. Some might wish to let stuff age a bit for stability's 
> sake, but not excessively, and dates might help with that.

Yeah I don't see any way to accommodate that. Ports get updated all the time, 
as maintainers get around to it, and are often interdependent, so we can't 
support the notion of a user upgrading some ports but not others. It works 
sometimes, when the limited sets of ports you want to update doesn't depend on 
the ports you don't want to update and vice versa. But officially we recommend 
that users run "sudo port upgrade outdated" to upgrade all outdated ports.

Anytime something doesn't build, file a bug report so we can figure out what's 
wrong and fix it ASAP or if you can figure it out and fix it, file a pull 
request.


> A possible alternative: a reasonably easy way to keep only the most recent X 
> inactive versions of a port with a given set of variants. That way one could 
> keep things reasonably clean but have something to fall back to. If there's a 
> non-manual way to do that (short of a creative script that digests the output 
> of "port installed"), I must have missed it.

There isn't anything built-in to do that. It could be scripted, as you suggest. 
"port reclaim" deletes all inactive ports, I believe. It wouldn't be 
unreasonable to enhance it with the ability to keep the n most recent versions 
of each port.