incr revision / portindex

[Ryan Schmidt]

On Oct 29, 2021, at 01:06, Joshua Root wrote:

> On 2021-10-29 10:03 , Daniel J. Luke wrote:
>> Hi macports-dev,
>> Looks like the change in 10aaad9b10e7350e76676ebdb5acfc950b800273 caused behavior I didn't expect on my Monterey system. Since I'm using a git checkout for my portfiles on that host and I was running darwin 20 when I did `port sync` after that change hit, my portindex had, for example 1.5.0_1 for zstd. After upgrading to Monterey, that means 'port outdated' thinks zstd is outdated, but trying to install it installs 1.5.0_0. (so `port outdated` still thinks it's outdated).
> 
> This was also reported as <https://trac.macports.org/ticket/63685>.
> 
>> Easy fix for me is to blow out my PortIndex and create a new one - but this is the first time I think I've ever had to do that when upgrading macOS.
>> I'd suggest that we should avoid having platform (or variant) blocks change any of epoc,version,revision even in a case like this (when presumably that was done to avoid unnecessary rebuilds for some people).
> 
> I would generally agree. In cases where different platforms need different versions, the approach used by ld64 with separate (sub)ports per version is preferable.

Either we allow portindexes that differ by OS version and arch (and we currently do), or we do not. 

Since we do, there is nothing wrong with the commit in which I increased revisions conditionally only on Big Sur.

The bug is that MacPorts base does not recognize that a portindex was built on a different OS version than the one that is currently running; that should be fixed.

Any number of other port differences can be OS version or arch specific. For example, some ports may offer different port versions on different OS versions or different OS archs as needed. Such ports would also be affected by this problem.