| +- public-package-0.2.tar.gz
| +- public-package-0.2.tar.gz.asc
| +- public-package-0.2.tar.gz.sha256
+ | +- public-package-0.2.tar.gz.blake2_256
+-- private-package
| +- .internal
| +- .metadata.rec
| +- private-package-0.1.tar.gz
| +- private-package-0.1.tar.gz.asc
| +- private-package-0.1.tar.gz.sha256
+ | +- private-package-0.1.tar.gz.blake2_256
|...
@end verbatim
@file{.sha256}, @file{.blake2_256}, @file{.sha512}, @file{.md5} files.
However no package package tarball is downloaded.
-If JSON API is enabled, them metadata is also downloaded and stored in
+If JSON API is enabled, then metadata is also downloaded and stored in
@file{.metadata.rec} @url{https://www.gnu.org/software/recutils/, recfile}.
-It fully resembles Core Metadata structure.
+It fully resembles structure of
+@url{https://packaging.python.org/specifications/core-metadata/, Core Metadata}.
When you request for particular package version, then its tarball is
downloaded and verified against the stored checksum. But SHA256 is then
long time ago with MD5 checksum. @code{0.1.1} version is downloaded more
recently with BLAKE2b-256 checksum, also storing that checksum for
@code{0.1}. @code{0.2} version is downloaded tarball, having forced
-SHA256 recalculated checksum. Also upstream has corresponding
-@file{.asc} signature file.
+SHA256 and BLAKE2b-256 recalculated checksums. Also upstream has
+corresponding @file{.asc} signature file.
@file{private-package} is private package, because it contains
@file{.internal} file. It can be uploaded and queries to it are not