I'll consider it.

I'm currently splitting the matrix-archive-keyring source package into two binary packages: matrix-archive-keyring and matrix-archive-sourcelist.

Building from source will build both.

Maximus: Hi hi, an update. This one took very long, messing around with gpg wasn't nice... UX improvements.

• The question about APT trust anchor will be always asked now, if the "bad keys" (APT trust anchors) were removed. Previously, you had to dpkg-reconfigure for this. The default is still "false" to install it.
• Split to matrix-archive-keyring and matrix-archive-sourcelist binaries, one source. matrix-archive-sourcelist is the APT sources.list(5) configuration and depends on matrix-archive-keyring. ** This was done to mark the matrix-archive-sourcelist package as i386 and amd64 architecture only. ** Since there was a package split, matrix-archive-sourcelist requires matrix-archive-keyring version 2015.12.09+debian0.12 or later.
• All trust.gpg and trust.gpg.d files will now be scanned for Matrix.org's keys (except the one from this package 😉) for removal.

APT config files are still being overwritten (data loss in matrix-org.list), still looking for some kind of a solution.

And some documentation updates, rewrote the changelog too.

All trust.gpg and trust.gpg.d files will now be scanned for Matrix.org's keys (except the one from this package 😉) for removal

Not exactly true either. It must be *.gpg or *.asc, and must not be a symlink.

The question about APT trust anchor will be always asked now, if the "bad keys" (APT trust anchors) were removed.

So the previous logic was:

if find_bad_keys; then
    # always show bad keys warning
fi

# low priority trust anchor question

Now it is:

if find_bad_keys; then
    # always show bad keys warning
    # high priority trust anchor question
else
   # low priority trust anchor question
fi

but it will remember the answer for the trust anchor question, anyway

Matrix.org doesn't have packages for other architectures.

I guess one could fetch the sources from there, though.

There's two checks: One at config time, one in the debian/control file.

Oh, I meant they have no binary packages.

only i386 and amd64

I also don't think the create_source_list() function would work on anything but amd64 and i386.

Well okay, it would. I forgot I don't use the Architecture option in the sources.list(5) file, and I wouldn't use $(ARCH) anyway.

I can change it back to all, but then you'd hit this piece of code:

# Matrix.org has supplemental packages for i386 and amd64 architectures only.
case "$(dpkg --print-architecture)" in
    i386|amd64)
        # Try to remember the previous choices to debconf(1) questions, even if
        # it's cache is gone.
        #
        # The other way of thinking this is if the sysadmin attempted to
        # configure APT data sources manually before installing
        # matrix-archive-sourcelist, we'll suggest "yes" as the default.
        [ -e "$APT_SOURCESLIST_M" ] && \
            db_set matrix-archive-keyring/sources.list "true"
        db_input high matrix-archive-keyring/sources.list || true
        db_go || true
    ;;

    *)
        echo "Unsupported architecture; refusing to configure APT." >&2
    ;;
esac

I also don't differentiate, both deb and deb-src get activated

But good point, I guess I could try to make it conditional to enable deb only if it's an architecture it knows about

or just let APT guess

Linda

reverts it back to Architecture: all

and removing this i386|amd64) case

I agree. I'm not sure what the sensible default is:

1. A medium priority debconf(1) question when we're not on i386 or amd64; or
2. Disregard architecture for sources.list.