Re: privoxy-pki-bundle not Behaving as Desired – Request for Assistance

[Daniel J. Luke]

On May 24, 2022, at 3:56 PM, Ryan Schmidt <ryandesign at macports.org> 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)

>> 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.

-- 
Daniel J. Luke