Subject: pkg/26448: resuming pkgsrc distfile fetches implementation is poor
To: None <>
From: None <kre@munnari.OZ.AU>
List: pkgsrc-bugs
Date: 07/27/2004 20:05:24
>Number:         26448
>Category:       pkg
>Synopsis:       resuming pkgsrc distfile fetches implementation is poor
>Confidential:   yes
>Severity:       critical
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 27 13:07:00 UTC 2004
>Originator:     Robert Elz
>Release:        NetBSD 1.6X  (--pkgsrc as of date of this message)
System: NetBSD 1.6X NetBSD 1.6X (JADE) #17: Wed Sep 24 20:25:35 ICT 2003 i386
Architecture: i386
Machine: i386
	The new feature that causes pkgsrc to automatically attempt to
	resume fetching of an interrupted distfile fetch is well motivated,
	but not necessarily a good idea (certainly not always a good idea)
	and needs to be at least made optional (so it can be disabled),
	but worse than that, the implementation currently assumes that if
	the distfile fetched is not the exact size that was expected,
	then the fetch must have been interrupted - nothing is less likely,
	in most environments, the more likely cause is that the distfile
	fetched has changed from the one expected, and that's why the
	size is now different.   As implemented now, the file will just
	keep on attempting to resume being fetched, always getting
	nothing any different from what was fetched last time (one hopes).
	By code inspection.
	For now, just delete the feature (revert to what existed before)
	until a properly worked out solution can be found.

	At least, it needs an on/off switch.

	The test probably needs to be "is substantially smaller than"
	rather than "is not equal to" when comparing the sizes (that is,
	not just 50 butes smaller fetched than intended...)

	And parsing ls -l output with awk may be the most portable way to
	find the size of a file, but it is is horribly unreliable with some
	versions of ls (that simply allow fields to run together when the
	numbers get big) - maybe it is the best possible, but it does need
	some thought.