On Jan 2, 2011, at 13:36, Marko Käning wrote: >> Personally I'd go with just using the macports mirrors for now. That at >> least puts the problem off until the next upstream release. > > Yeah, it's annoying. Heck, I should have learnt about where and how to put it > in a MacPorts mirror right at the start and not played around with BB > downloads. :-(
Well, the MacPorts mirrors work transparently. Wherever your distfile is hosted, the main MacPorts mirror in California will try to fetch it as soon as you commit the port. And the other mirrors periodically download new files from the main mirror. We only manually upload distfiles directly to the primary distfiles mirror as a last resort, when there is no other location where a project's distfiles might already be hosted. This is rare. The problem here was I think that you were using a BitBucket-generated distfile, and they did not keep the distfile around anywhere; they re-generated it later, after you had already recorded its checksums into the portfile. I recall there was at least one other DVCS site that was doing something similar, which made it unsuitable for use as a MacPorts master_sites location. Normal software release methodology would probably dictate that when packaging up a release tarball (or whatever distribution format has been chosen), the developer uploads this package to a server, and that file then stays there forever and never changes. And that's the purpose of the checksums in the portfile -- to verify that this procedure has been followed; to verify the distfile has not changed. For if it has changed, who's to say it still works properly? who's to say an attacker hasn't replaced it with malware? _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
