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.
