On 2017-05-26, Steffen Möller wrote: > I am with Alex (my past AM, hello) that the current policy has mostly > worked. I think so too... > But I also tend to think that we need something for communities > that have their very own understanding of what a release is that is > mostly independent from the underlying OS. Ubuntu can get there via > their PPA infrastructure but I find that confusing since the user does > not know what PPA to trust and which not so much. My subject line was a > bit of a provocation, but could we think about a concept that would both > be close to the distribution and allow for the needs of particular user > community? A team that wants to maintain packages not quite appropriate for backports could ship TEAM-archive-keyring packages in Debian; there are several examples of this or something similar in the archive already: debian-ports-archive-keyring emdebian-archive-keyring leap-archive-keyring neurodebian-archive-keyring pkg-mozilla-archive-keyring Then said team could set up a TEAM.debian.net subdomain, and host packages in a repository signed by the key(s) included in the corresponding *-archive-keyring packages. This provides a reliable trust path from Debian to the keys, so shouldn't have as much of a problem as with Ubuntu PPAs to decide which repositories to trust. It's not without downsides; this does require the team to be willing to manage their own repository infrastructure, of course. It doesn't integrate with other infrastructure such as tracker.debian.org or bugs.debian.org. If teams require backports (or even out-of-archive ports, e.g. django 1.8) from packages maintained by other teams, it gets interesting, especially if multiple teams want to host the same packages. Hopefully it wouldn't end up with hundreds of *-archive-keyring and corresponding "external" repositories; that would be messy. It's not perfect, but it's an option. live well, vagrant
Attachment:
signature.asc
Description: PGP signature