Ryan Schmidt writes: > On Sep 30, 2014, at 4:55 PM, Sean Farley wrote: > >> As for this exact issue, it could be something as simple as a fallback >> test: >> >> if checksum doesn't match and revision is new: >> try downloading again >> write state so we don't download in an infinite loop > > That's a conceivable change. But let's look at what problems that particular > change would involve: > > * MacPorts would need to gain the capability to go back to a previous phase > (fetch) after it has already been completed. Or perhaps simpler, MacPorts > would need the ability to automatically clean a port and try it from the > beginning based on some criteria. This would be quite useful for a number of > issues MacPorts users currently experience, but it's not a capability that > exists today.
This is a very real issue. Difficult to do in today's code base. > * It assumes the port's revision will be increased. That's not always > necessary. Sometimes the only change in the distfile is the name of (or > presence of) the enclosing directory, or there are only changes in comments > or documentation files or other files that don't affect the build, and in > those cases there would be zero benefit to increasing the port's revision and > forcing everyone to rebuild or redownload. That's true. In this case, we should borrow an idea from DVCSes: use a hash to see if something has changed (probably something like a Merkle tree). This would be a nontrivial amount of work but would help mitigate the whole 'epoch' business. > * The old distfile would get removed from our mirrors, making it impossible > for anyone to later determine what exactly changed in the stealth update. > Many maintainers handle stealth updates incorrectly. It is nice for others to > be able to investigate after the fact. If we used hashes in the distfile naming, we wouldn't be overwriting things. These are all just ideas / vague shots in the dark. I'm not volunteering to do this work :-P _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
