Where should things live?

Just a random ticket with a comment I wrote on slack;

I'm still undecided where the specs/rules would live best.

deb/rpm specs and rules in each repository

• PRO it's more "standard"? (people could build from the repo using standard tooling if it's in the expected location)
• PRO repo maintainers can also update the spec/rules if things change in the source/project
• PRO repo maintainers can test packaging before releasing
• CON is that repo maintainers now must update spec/rules if things change in the source/project (and packaging is an expertise not everyone knows all details about)
• CON is that ^^ if fixes are needed for packaging (in the spec/rules), those now require a new release

deb/rpm specs and rules in a central repository

• PRO maintainers with expertise on packaging (and all its quirks) can maintain the specs/rules, applying "best practice" and consistency
• PRO "packaging only" updates to specs/rules can be made independently of project releases (which includes changes to packaging related to "new distros added" or "EOL distros removed"
• CON less standard? (deb and rpm tools work well with specs/rules living together with the source?)
• CON when do we test packaging? We may discover issues after projects did a release.
• CON maintaining the files would become a shared responsibility, and maintainers of the packaging repository may not be notified / may not be aware when things change in project repositories.
• CON less likely to receive contributions
• PRO/CON central place to maintain the list of distros to package for (but could be communicated to the projects in other ways)

TBD how often the specs need updates; might be less complicated for CLI tools, but of course the devil is in the detail; some changes may be distro-specific, not due to changes in the project. Thinking of things like; https://github.com/docker/containerd-packaging/blob/6e368fae00d9e02d7eca6f751416c026516ece98/rpm/containerd.spec#L54-L57

TL;DR; either way makes sense, either way has pros/cons

Start by reviewing the issue's two proposed locations for deb/rpm specs and rules, including the listed pros, cons, and the linked containerd packaging example. Done means reaching and documenting a decision about repository ownership, update timing, testing, distro coverage, and how changes will be communicated.