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

[Ryan Schmidt]

On May 24, 2022, at 09:35, Daniel J. Luke wrote:

> - MacPorts could grow a feature by which a port could specify that it needs to get rebuilt if something it depends on gets rebuilt (this would probably require another identifier along with epoch-version-revision or would require some magic behavior with one of the existing versioning numbers)

> So far, when people encounter this problem, there hasn't been enough motivation for anyone to build a MacPorts feature to support it (but I'd be happy to see one).

I'm not convinced that I would be happy to see such a feature. Just a moment's consideration shows how many different parts of MacPorts would need modifications to support it, not only in base but also in the buildbot and in the package hosting infrastructure. And in the end, what we end up with is a rather fundamental violation of a principle we currently rely on, which is that a given version and revision of a port is (unless there is a bug) reproducible, immutable, deterministic.

For example, imagine that at 1pm curl-ca-bundle is updated to a new version and privoxy-pki-bundle uses this hypothetical new feature that makes it reinstall when curl-ca-bundle is updated. To get there, we'd have to modify the registry to store what version of curl-ca-bundle was installed at the time that privoxy-pki-bundle was installed, and we'd have to extend the portindex to hold information about which ports should trigger a reinstall for another port, and we'd have to enhance base's understanding of outdatedness to make use of this new information, and enhance "port outdated" to display that information. And suppose we have modified the buildbot to know that it must rebuild privoxy-pki-bundle and upload a new package. (Currently it decides whether to build a new package in part based on whether a package with the correct filename already exists on the server, which now won't be sufficient criteria.) It takes awhile for newly uploaded packages to sync from the private server to the public one, so let's say by 2pm the new curl-ca-bundle and privoxy-pki-bundle packages have synced to the public server (although there's no guarantee that they'd both be there at the same time -- the new curl-ca-bundle package, having been built first, might arrive 30-60 minutes ahead of privoxy-pki-bundle). Our mirrors sync from the public server at varying intervals, so let's say that by 10pm the new packages are on all the mirrors. Prior to that time, old packages of the same filename might still be on some mirrors. What happens if a user upgrades to the new curl-ca-bundle at 5pm? If the new curl-ca-bundle package is available on any mirror they access, that'll be used, otherwise the new curl-ca-bundle will be built from source. Fine. Then MacPorts will want to reinstall privoxy-pki-bundle, even though its version and revision are the same, due to the new hypothetical feature. It will check for a package on a mirror and it will find one! But will it be an old package or a newly rebuilt one? No one knows.

If the proposed workaround for this is that ports using this new reinstall feature should program themselves never to use prebuilt packages, then that's another reason to dislike the new feature. (Users like receiving binaries and not having to build things from source.) Or perhaps the proposal is that package filenames should grow even longer with an additional identifier -- which would hopefully be empty for ports not opting in to this new thing so that all our existing packages are not invalidated. If so, what would the new identifier be?