Giters

redis / redis-debian

Debian packaging

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[BUG] Incomplete repo data

aonsyed opened this issue · comments

commented

Describe the bug

Repo is missing Origin, Lable, Suite, Version and Description

To reproduce

Here are the first few lines of the repo aka metadata

curl -s https://packages.redis.io/deb/dists/jammy/InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Codename: jammy
Date: Sun, 08 Oct 2023 08:18:57 UTC
Architectures: amd64 all i386 armhf arm64
Components: main
Suite:

Expected behavior

Here is what a standard repo should have

curl -s https://ppa.launchpadcontent.net/redislabs/redis/ubuntu/dists/jammy/InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Origin: LP-PPA-redislabs-redis
Label: Redis
Suite: jammy
Version: 22.04
Codename: jammy
Date: Wed, 06 Sep 2023 23:45:50 UTC
Architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390x
Components: main
Description: Ubuntu Jammy 22.04

Additional information

Please make sure that the additional info is provided, it helps with tagging and pipelining upgrades, same applies for Release in addition to InRelease

commented

@aonsyed These are optional fields that are not mandatory. Launchpad uses them in certain way, but that doesn't mean any repository have to follow these conventions. Can you please provide more information about how this breaks pipelines?

commented

Label suite version and origin make it much easier to identify those details. Right now the only identifying information is that the site is packages.redis.io with the correct gpg key, however since most of the OSS software uses third-party mirrors, these additional fields make it easier to detect those irrespective of the URL and most of upgrade mechanism like unattended-upgrades

Here is a chunk of 50unattended-upgrades on debian based OSes

Unattended-Upgrade::Origins-Pattern {
        // Codename based matching:
        // This will follow the migration of a release through different
        // archives (e.g. from testing to stable and later oldstable).
        // Software will be the latest available for the named release,
        // but the Debian release itself will not be automatically upgraded.
//      "origin=Debian,codename=${distro_codename}-updates";
//      "origin=Debian,codename=${distro_codename}-proposed-updates";
        "origin=Debian,codename=${distro_codename},label=Debian";
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

As you can see most of it is based on the missing parameters, so anyone using unattended-upgrades would have to change the pattern values to include the site info specifically and that would only work till Redis repo is starts being mirrored by others.

Additionally any other DevOps related work that uses data from InRelease to read the repo meta data for info and then do anything with the packages present like updates or version pinning or anything else would need extra steps to recognize the data from the URL instead of additional fields that are present for almost every other debian-based repo

commented

@aonsyed We'll use packages.redis.io as Origin and change Suite to match Codename. Unfortunately, the deb-s3 tool we use doesn't seem to support adding a Label field, I hope those two are sufficient though.