pkg.freebsd.org "hash_latest" repository introduction in FreeBSD:14:amd64

[T.J.Newton]

Hello list,

I always pkg-fetch(8) packages for upgrade, or new, from the "latest"
repo into a local repository to NFS distribute them to multiple machines.

I've noticed a few days ago the fetched packages of FreeBSD:14:amd64 are
stored in a automatically by pkg(8) (v 2.4.2) created new sub-directory
named "Hashed" and the packages have, I suppose, considering the
directory name they are saved into, a hash tag in their names, e.g.:

New fetched files names:

vlc-3.0.21_20,4~7253d15082.pkg
x265-4.1~ebe69c23d8.pkg
xorg-server-21.1.20,1~fe5c37c403.pkg

Older versions file name: vlc-3.0.21_19,4.pkg

Local repository path after pkg-fetch(8) :
/.../FreeBSD:14:amd64/latest/All/Hashed

Remote repository: https://pkg.freebsd.org/FreeBSD:14:amd64/hash_latest/

Remote repository configuration:


latest: {
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}


No other ABI (13, 15, 16) has the "hash_latest" remote repository
(https://pkg.freebsd.org).

I tried to get information about this particular repo, but so far I had
no success. Does anyone have any information about the "hash_latest" repo?

Best regards

[Dave Cottlehuber]

Hi TJ

As part of 15.0-RELEASE the project is also making use of some CDN-backed
mirrors, to give better download and package performance.

This is also how the FreeBSD base system packages are distributed.

This in turn requires that packages we build have unique names, so that
we can sync the packages themselves, without collision, and then only at the
end, update the final metadata, after each package release, per architecture,
release, and ports branch.

This was only recently switched on, and are hashed directories are trickling
out over the next few weeks, as each package repo is rebuilt.

I'm not certain but I think 15.0-RELEASE is special, and the /latest/ ports
branch is already using hashes within the metadata.

Hopefully somebody from clusteradm will chime in and correct any egregious
mistakes in the above.

A+
Dave