feat: Use deb822 format for APT sources

[blieque]

Description

Replace armbian-config.list with armbian-config.sources. This holds the same information in a newer format, deb822. APT has supported this format since version 1.1, released in 2015.

README.md is also updated, and some typos are fixed.

This does not affect armbian.list, but I could look at migrating that too if there is interest.

There are two more references to armbian-config.list that will also need to be updated in other repositories to merge this PR:

• armbian/build: extensions/armbian-config.sh
• armbian/documentation: docs/User-Guide_Armbian-Config.md

A migration script in a post-install hook might also be required.

Issue reference: n/a
Related documentation: deb822

[igorpecovnik]

How is backward compatibility? Bullseye / Focal? Where this breaks?

[dimitry-ishenko]

I can confirm that both Focal and Bullseye support the new format.

For the test I've replaced the standard sources.list file with 50-ubuntu.sources for Focal:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: focal focal-updates focal-backports focal-security
Components: main restricted universe multiverse
Architectures: amd64
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

and 50-debian.sources for Bullseye:

Types: deb
URIs: http://deb.debian.org/debian
Suites: bullseye bullseye-updates bullseye-backports
Components: main contrib non-free
Architectures: amd64
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://security.debian.org/debian-security
Suites: bullseye-security
Components: main contrib non-free
Architectures: amd64
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

[igorpecovnik]

but I could look at migrating that too if there is interest.

Absolutely, any help is appreciated! Thank you for this one.

[blieque]

Thanks, both. I think all Debian and Ubuntu releases from ~2017 onwards support deb822.

APT versions:

• Ubuntu Focal: 2.0.2
• Ubuntu Xenial and possibly Bionic: 1.1+
• Debian Buster: 1.8.2.3
• Debian Bullseye: 2.2.4

It's more likely that issues are created by scripts and third-party software which interacts with the APT sources. armbian-config, for instance, modifies armbian.list in a number of places, e.g.:

[[ -f /etc/apt/sources.list.d/armbian.list ]] && sed -i "s/$distroid/$upgrade/g" /etc/apt/sources.list.d/armbian.list

Would you like armbian-config to retain this code if I add support for armbian.sources, or should I replace it? Also, would you recommend automatically migrating armbian.list and armbian-config.list on users' systems to .sources files? If so, where would this code best live?

Before merging this PR, see these two:

• docs: Use deb822 APT source for armbian-config documentation#616
• feat: Use deb822 APT source for armbian-config build#7782

[dimitry-ishenko]

Thanks @blieque. Few small notes:

1. Both Ubuntu and Debian use http in the URIs, as https requires ca-certificates and openssl packages to be installed, which may not be installed/desired on minimal systems.

2. Manually installed keyrings (as opposed to the ones installed by the package manager) should be located in /etc/apt/keyrings.

@igorpecovnik please correct me, if I am wrong on the above points.

Also, this is probably a subject for another issue, but IMHO armbian and armbian-config keys should be provided by a .deb package, like Ubuntu and Debian do (ie, ubuntu-keyring and debian-archive-keyring).

[igorpecovnik]

please correct me, if I am wrong on the above points.

You are correct. We provide ca-certificates package on all our builds, so this is not a problem. There is also hard dependency on openssl so in theory this should work as proposed. Still I would rather move this feature development for next release.

Manually installed keyrings

I think yes.

I have opened a ticket https://armbian.atlassian.net/browse/AR-2601 Is this all that needs to be fixed within?

armbian and armbian-config

Do we produce two packages or one? I don't want that we sign this with a different key.

[igorpecovnik]

I'll merge this as is. https will work for armbian repositories and we had https before, so this is not a problem. For Debian I don't know.

[blieque]

The Debian manpage says this:

The recommended locations for keyrings are /usr/share/keyrings for keyrings managed by packages, and /etc/apt/keyrings for keyrings managed by the system operator.

I assume that manual installation of armbian-config on other distros is rare, but in that case /etc/apt/keyrings/ is the right place for armbian.gpg.

On Armbian, though, the key almost certainly originated with the installation image. I wouldn't consider this "managed by packages" or "managed by the system operator", although I'd lean toward the former. I feel like /etc/apt/keyrings/ is intended for third-party repositories, e.g., NodeSource for Node.js builds. Few Armbian users will have manually downloaded their copy of armbian.gpg, so it's a system responsibility. I'd opt to leave the key in /usr/share/keyrings/ while developing an armbian-archive-keyring package which takes over that file.

There are at least 14 mentions of /usr/share/keyrings/armbian.gpg across these repositories that would need to be changed:

• armbian/build
• armbian/config (superseded)
• armbian/configurator
• armbian/configng
• armbian/documentation

A lot of these references include references to armbian.list, too. It seems like a lot of hassle to change the key path only to change it back once a keyring package has been created.

[igorpecovnik]

armbian/configurator

Also deprecated.

[dimitry-ishenko]

Do we produce two packages or one? I don't want that we sign this with a different key.

@igorpecovnik no sorry, we would just have one package, eg armbian-keyring.

I wouldn't consider this "managed by packages" or "managed by the system operator", although I'd lean toward the former.

@blieque I see it differently, but if we are going to go with the package, our differences are unimportant. I gave it another thought, and I agree with you - it's better to keep the key in its current location. This way when we roll the package, it will simply overwrite the existing file.