On Mon, May 16, 2011 at 10:14:11AM +0200, David Demelier wrote: > On 16/05/2011 09:02, Andriy Gapon wrote: > > > >I've noticed the following problem. > >If a distfile is updated by a distributor without renaming it (so that > >checksum > >and possibly size change), then more often than not the port build system > >would > >fail to fetch the distfile. > >An example: > >... > > => SHA256 Checksum mismatch for > > eclipse/javax.servlet.jsp_2.0.0.v200806031607.jar. > >... > >=> javax.servlet.jsp_2.0.0.v200806031607.jar doesn't seem to exist in > >/usr/ports/distfiles/eclipse. > >=> Attempting to fetch > >http://download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/bundles/javax.servlet.jsp_2.0.0.v200806031607.jar > >fetch: > >http://download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/bundles/javax.servlet.jsp_2.0.0.v200806031607.jar: > >Requested Range Not Satisfiable > >=> Attempting to fetch > >ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/eclipse/javax.servlet.jsp_2.0.0.v200806031607.jar > >fetch: > >ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/eclipse/javax.servlet.jsp_2.0.0.v200806031607.jar: > >size mismatch: expected 63889, actual 62707 > >=> Couldn't fetch it - please try to retrieve this > >=> port manually into /usr/ports/distfiles/eclipse and try again. > >*** Error code 1 > > > >I think that this happens because the old version of the distfile is still > >present in download target location and fetch(1) thinks that it has a > >partially > >downloaded file and tries to be smart. [snip simple patch] > > make -DNO_CHECKSUM=yes ... is probably what you want, I guess.
I think that Andriy is referring to the following case which has bit me, too, more than once: 1. Upstream releases a new version. 2. The port is updated to the new version. 3. The user fetches the new version, builds and installs the port. 4. Upstream makes a change without bumping the version. 5. The port maintainer curses a bit and updates the port, possibly bumping PORTREVISION if upstream changed something important 6. The user tries to fetch the new version of the upstream tarball and stumbles into fetch(1)'s outright refusal :) In this case, NO_CHECKSUM would be quite... counterproductive, in case the user really cares about security and integrity :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 Nostalgia ain't what it used to be.
signature.asc
Description: Digital signature
