On May 24, 2022, at 15:31, Daniel J. Luke wrote: > On May 24, 2022, at 3:56 PM, Ryan Schmidt wrote: >> I wouldn't recommend anyone begin writing any code until it is discussed how >> the feature should work. That should avoid spending time writing code that >> won't work. > > sure, if someone were working on a feature it would be reasonable for them to > discuss it here ... (but again, no on is). > >>> - but there are of course possibilities here. We could (ab)use epoch, >> >> epoch can't be used because epoch is not part of the archive filename, and >> because it is within the portfile author's control when to change the epoch. > > then epoch can't ever be used for anything because it has the same 'fatal' > problem (if I bump epoch in a port I maintain, and use a version + revision > that there's already a package for ... I guess we tell people "don't do that" > - but there's nothing preventing someone from doing it by mistake)
Correct, don't do that. epoch can be used if you use it for what it's for. For example, consider you have a port foo with epoch 0, version 2.0, revision 5. Archives have been built, users have installed them, it works fine. Now you update the port to epoch 0, version 3.0, revision 0. Archives get built, some users upgrade to this version, and they report that it does not work. Nobody knows why, and to avoid this problem, you want to downgrade the port to the last working version. To do this, you set version back to 2.0, set revision back to 5, and increase epoch from 0 to 1. Any users who had already upgraded to version 3.0 revision 0 will be downgraded back to version 2.0 revision 5. In doing so, they may receive the previously-built version 2.0 revision 5 archives from the server, which are still fine. Users who never upgraded to version 3.0 revision 0 are not prompted to reinstall anything since that would be unnecessary. Some time later a solution to the 3.0 problem is found and you wish to upgrade the port to 3.0 with a patch to fix the problem. To do this, you leave epoch at 1 (as you will forever unless at some time in the future you again wish to make the version decrease), set version to 3.0 again, set revision to 1 this time (since revision 0 of 3.0 was bad), new archives will be built, users will upgrade, etc. >>> just have portindex increment the revision for the ports that request to be >>> rebuilt when a new version of something is added, >> >> How? The PortIndex file is generated by extracting certain information from >> each port. Right now, an up-to-date PortIndex file contains the fact that >> privoxy-pki-bundle has epoch 0, version 3.0.33, revision 3, because that's >> what it said in the privoxy-pki-bundle Portfile when that PortIndex entry >> was written. Suppose tomorrow I update curl-ca-bundle to a new version. By >> what means is the portindex program supposed to know that now, it should >> record revision 4 in the PortIndex file entry for privoxy-pki-bundle? If you >> are suggesting that it should read the existing entry from the PortIndex >> file, increment revision, and write it back, that won't work because it is >> valid to delete the PortIndex file and regenerate it from scratch. > > Because it's impossible to change how portindex works? It's impossible to > store any state other than state that's already stored? I'm purposely not > writing up a comprehensive design here - since I've not volunteered to > implement it and I don't think it's worthwhile to do an exhaustive feature > design if no one is doing an implementation. (and also, if someone else > decides to implement it, I don't want to constrain them since I haven't > really dug into the details). > > I feel like the few times we've discussed this we talk past each other > because I'm operating on the assumption that whoever implements a new feature > isn't constrained in what parts of MacPorts they would modify while you > appear to be focused on what would break with the smallest possible > implementation (and by extension, why that feature isn't possible to > implement). > > Fundamentally the current situation is that we have cases where this kind of > dependency exists. We deal with it now by adding a comment + having a human > do something. I'm just saying that software could be written to do the right > thing here and I would welcome the automation. Implementation would, of > course, take time and require consideration of all of the other pieces of > MacPorts (and infra) that it touches. When I said "How?" I was trying to convey that I could not imagine a way to accomplish what you propose. And your answer is that you won't discuss it. So we remain at an impasse. Your comment that we shouldn't bother designing a feature if nobody is implementing it seems exactly backwards to me. Obviously a design is needed first before anyone would consider implementing anything.
