pkg versions don't match

[Matthew Seaman]

On 21/12/2014 02:25, Alejandro Imass wrote:
> Yeah but something doesn't seem quite right here. The option -f "force" to
> check origin versions seems a bit obscure. If -f is needed for update to
> actually check remote for update then it should be more prominent.
> 
> The manual clearly states:
> 
> pkg update is used for updating the local copy of the repository catalogues
> from the remote package repository databases.  Updates to catalogues are
> normally downloaded only when the master copy on the remote package
> repository is newer than the local copy.
> 
> So it _seems_ that update does not actually check remote pkg repository
> without the use of -f
> 
> Assuming -f is needed to go and actually fetch the new versions then when a
> package is not found on remote, it should be prominent in handbook page,
> the main man page,  or at least hint the user to try -f when "not found".

pkg(8) will "update the repo" automatically as part of many different
operations. 'pkg update' essentially runs this bit of code alone,
without doing any other operations.  However, the only way to force the
repo to be updated is via 'pkg update' -- everything else just runs the
normal update algorithm.

When pkg(8) updates the repo, it does a series of things.  Firstly it
downloads a copy of the repo catalogue -- that's a compressed file of
JSON data with selected bits of package metadata for all of the packages
in the repo.  In order to avoid this resulting in a lot of unnecessary
work, pkg(8) basically checks to ensure that the timestamp on the
repository catalogue is unchanged using the standard HTTP 304 'Not
modified' status code mechanism.  If it finds the catalogue hasn't
changed since the last time it downloaded it, then it stops there.

(The slow step here is downloading the repo catalogue which can be of
significant size over a network link of unknown bandwidth -- the 'out of
date' check requires minimal network IO and is much faster, while the
local processing to load the catalogue into slite is orders of magnitude
faster still.)

Otherwise, if the catalogue has changed, or there isn't already a local
copy, then pkg(8) decompresses the catalogue and processes it into a
Sqlite database, which is what all subsequent pkg(8) operations query.

What force does is override the 'is the catalogue unchanged from last
time' test, so pkg(8) will always download and reprocess the catalogue.
Usually this is unnecessary, as there's no point in redownloading
exactly the same thing and reprocessing it to produce exactly the same.
There is one circumstance when this is not true however: when pkg(8)
itself is updated, the schema of the sqlite database may change.  The
format of the catalogue may similarly change, but it is carefully done
to remain backwards compatible with both older and newer versions of
pkg(8).  Changes to the catalogue format and to the sqlite schemas are
mostly handled completely transparently to the user, but occasionally,
as in this case, forcing the update is required to populate the
new-style repo catalogue.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 971 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20141221/72cbb4e3/attachment.sig>