debian: support additional suites

[nmeyerhans]

This is a proposed solution to the ability to specify a repository suite in the Debian configuration, in addition to the components currently specified. The optional suite is specified as a prefix to the component name in the Repositories= config setting, e.g.

Repositories=
    non-free-firmware
    trixie-backports:main
    trixie-backports:non-free-firmware

The trixie-backports: lines above would generate the following content in the resulting trixie.sources file:

Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: trixie-backports
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Fixes #1755

[behrmann]

This is not very large, but it's very specialised to Debian. The canonical way to do this is to just put these files into a package tree, since we can't really add options for everything a package manager does into mkosi itself.

[nmeyerhans]

This is not very large, but it's very specialised to Debian.

Well yes, it fixes a Debian-specific issue in a Debian-specific source file. Though theoretically the same issue impacts Ubuntu. It may be reasonable to refactor the apt repository handling code further to extract common code in such a way that it can be shared between ubuntu.py and debian.py, but that's out of scope for the original issue and for my use case, so I didn't do that here.

The canonical way to do this is to just put these files into a package tree, since we can't really add options for everything a package manager does into mkosi itself.

The existence of #1755 suggests that this is desirable functionality to have in mkosi. Configuring the package manager to retrieve directly from a repository avoids a number of potential issues with package trees (stale packages, missing dependencies, etc).

[bketelsen]

brilliant! I need this.

[behrmann]

Configuring the package manager to retrieve directly from a repository avoids a number of potential issues with package trees (stale packages, missing dependencies, etc).

Maybe I've been a bit unclear earlier, because I used an older term no longer used in our docs, but is there a reason you can't use a SandboxTree=? You can put arbitrary apt config files in there.

[nmeyerhans]

Configuring the package manager to retrieve directly from a repository avoids a number of potential issues with package trees (stale packages, missing dependencies, etc).

Maybe I've been a bit unclear earlier, because I used an older term no longer used in our docs, but is there a reason you can't use a SandboxTree=? You can put arbitrary apt config files in there.

Yes, we can certainly work around the limitation as you describe. But I wonder if that's the intended answer to #1755? It seems from there that there was a desire to have native support for apt suites within mkosi. If things have changed and that's no longer considered in scope, that's fine, but it would be good to note that in the issue.