Bug 243144 - ports-mgmt/pkg: size mismatch error
Summary: ports-mgmt/pkg: size mismatch error
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-pkg (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-06 23:22 UTC by doug
Modified: 2020-03-24 19:06 UTC (History)
2 users (show)

See Also:
linimon: maintainer-feedback? (pkg)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description doug 2020-01-06 23:22:27 UTC
In the event the local copy of the repository catalogue get corrupted the command 
"pkg update -f" must be run. I propose a change to both the error message and the PKG-UPDATE man page to suggest this. User's having been googling for this answer since 2014. I started using FreeBSD with version 4.5 and never hit this error until updating from 10.3 --> 11.3. I also had to google for the answer.
Comment 1 Conrad Meyer freebsd_committer 2020-01-07 01:27:01 UTC
Better yet, pkg should be able to detect this condition and perform the equivalent `pkg update -f` itself (unless `--no-repo-update` was specified).
Comment 2 Baptiste Daroussin freebsd_committer 2020-03-24 17:06:18 UTC
pkg now recommends to run pkg update -f, the bug is on the cluster side not on pkg side.
Comment 3 Conrad Meyer freebsd_committer 2020-03-24 19:06:09 UTC
It's a design problem.  We know package syncs are never going to be instantaneous, but the design of the pkg server infrastructure and client does not allow the client to install from a consistent snapshot (or even recognize the condition of an inconsistent sync status).

A better design would be to use content-addressed names on the server (i.e., some hash).  If the client gets a 404 error, it knows it has a stale index and must re-fetch metadata (automatically).  If the client does not get a 404, it will get exactly the file it asked for (modulo HTTP layer corruption) and the size check will not fail anyway.

Debian talks about something like this:
http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html