On Apr 3, 2012, at 18:21, Eric Cronin wrote: > On Apr 3, 2012, at 6:06 PM, MacPorts wrote: >> #33883: oxygen-icons @4.8.1 fetching failed, 404, checksum failed >> ----------------------------------+----------------------------------------- >> Reporter: reakinator@… | Owner: snc@… >> Type: defect | Status: new >> Priority: Normal | Milestone: >> Component: ports | Version: 2.0.4 >> Keywords: | Port: oxygen-icons >> ----------------------------------+----------------------------------------- >> >> Comment(by reakinator@…): >> >> Thanks for getting me getting me on the right track, and you're right I >> don't understand much of what macports is doing. :) >> >> Running "sudo port clean --all oxygen-icons" allowed me to get past the >> 404 error with the new DNS server (yet I read that from the linked wiki >> page, although it didn't mention the clean --all command, now I know). > > > > Would it make sense to put this information in the error message we print out > when checksums fail (something like "After investigating run 'port clean > --dist $portname' to remove the old file")? This is probably second to not > running clean at all in generating invalid trac tickets... I just updated > MisbehavingServers since that's where the error message points people, not at > the FAQ where we tell them about clean --dist...
I'm more in favor of moving towards all error messages just directing users to a specific wiki page for that error situation, where further explanations like that can be given, broken down into advice for users and advice for maintainers. Thanks for updating the wiki page; I agree that should be in there. > Even better from a POLA perspective would be adding some logic/state so that > until a file successfully checksums "port clean" removes the existing > download automatically... It's surprising enough to novice users that we > keep old downloads around indefinitely (Ryan's scripts are nice but hardly > novice-friendly), but really confusing that we try so hard to keep invalid > downloads around too. For the misbehaving DNS servers case, I still intend to commit the original solution I proposed, which makes MacPorts silently skip over the problem (like it already does for users who don't have misbehaving DNS servers) instead of bothering the user with it. For other cases, removing the distfile wouldn't help, since the distfile has presumably been stealth-updated; once the maintainer notices the problem and updates the port, they'll change the dist_subdir so the new distfile downloads to a new location anyway. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
