pkg versions don't match

Alejandro Imass aimass at
Sun Dec 21 13:15:41 UTC 2014

Thanks for the thorough explanation!

On Sun, Dec 21, 2014 at 5:48 AM, Matthew Seaman <matthew at> wrote:

> 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
> >


> 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.
This doesn't seem to be working very well or else why did my pkg keep
saying it was up to date and yet the packages in remote had clearly changed


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.

pkg did not get updated until after I forced pkg update so something else
did not work very well at least in my case (timezone issues?). In any case
the update process you describe with the metadata did not work.


Alejandro Imass

More information about the freebsd-questions mailing list