binary packages and Portfile changes

Jeremy Lavergne jeremy at lavergne.gotdns.org
Mon May 7 11:39:48 PDT 2012


> As far as I know things are working correctly the way they are today. What problem are you trying to solve? It sounds like you're saying MacPorts should compare the Portfile in the ports tree with the one in the archive, and if they differ, ignore the archive and build from source. If so, I see no reason to do that. If a Portfile change would result in a port needing to be rebuilt, the committer would have increased the revision. And if not, then there's no reason not to use an available archive. For example, just because someone decides to add a modeline or adjust a port's whitespace or formatting is no reason to discard an archive built from the previous Portfile.

I had one instance in mind:
 - port updated version
 - port was revised (revbump) to try to fix a runtime bug
 - whole version was bad so it was reversed and epoch'd

This leaves more than one future revision that will be bad.

When the port is finally updated again, the archives that were previously built are available should be considered bad; the maintainer will have to remember to go to n+1 revision number or the same issue originally trying to be fixed will crop up after it was fixed.

In that case, just increasing the revision won't suffice; it will need to be done a couple times. The maintainer will have to be careful of was used prior to the epoch increasing. Almost wonder why we don't just have an increment for every change that would install different files: regardless of it being an update or downgrade or what have you.


Aside: whitespace/formatting differences aren't worth addressing. Just slap -w (--ignore-all-space) on diff.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8796 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20120507/3a911ac5/attachment.bin>


More information about the macports-dev mailing list