patch for force fetch

[Peter Pentchev]

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	roam at ringlet.net roam at FreeBSD.org peter at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20110516/16c7ab8e/attachment.pgp