On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote: > Quoting Jonas Smedegaard (2019-02-12 19:38:57) > > I believe this package belongs in contrib, as its only use-case is with > > together with software outside of Debian main. > > ...and now posting to the actual bugreport as well.
I'm not opposed to having this matrix-archive-keyring package in the contrib area, although for comparison I should note leap-archive-keyring has no rdepends, the keyring package is available from Debian's main archive area and is valid for verifying package signatures from leap.se. An example of a package from deb.leap.se is bitmask-core (which is not available in Debian), and it's not in the contrib area in the leap.se repository. Maybe this is an error/bug in the leap-archive-keyring package, but it does seem confusing. The other *-archive-keyring packages in Debian main seem to be at least vaguely related to the Debian Project or its teams, although they are all (with the exception of debian-archive-keyring) meant to be used with third-party data sources (usually with APT). As of yesterday, there is also this high-priority debconf(1) question template in the matrix-archive-keyring package: Template: matrix-archive-keyring/sources.list Type: boolean Default: false _Description: Use APT data sources from Matrix.org? The Matrix.org Debian package repository distributes supplemental Matrix.org related packages intended to work with the Debian distribution, but require software software outside of the distribution to either build or function. These packages are digitally signed with keys from matrix-archive-keyring. . The Debian Project will be unable to directly support issues faced from using supplemental packages from this third-party repository. Packages from these APT sources may be non-conforming to the technical requirements set in the Debian Policy for the Debian distribution. (Sorry if I fell under the assumption the package will be usable on Debian only, and not derivative distributions with different names.) Choosing "yes" here would obviously enable the contrib bits from the default of "false". And as I said, packages from Matrix.org are already in the contrib area (Section: contrib/*). If this debconf(1) question makes it a hard-requirement of contrib archive area, I could split the main parts (keyring) and the debconf(1) question (sources.list) to seperate packages in main and contrib sections respectively if that is more desirable. I have currently set the package's "Section:" to "contrib/misc", in any case. What do you think?