Where should things live?

[thaJeztah]

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

[thaJeztah]

/cc @crazy-max @tianon

[tianon]

Wearing my Debian hat, I would 100% recommend keeping packaging in a separate repository. The tooling builds with it in the same repository, but it's not typically maintained that way, especially since packagers can very rarely use much if any of the upstream packaging bits and because they often have to maintain different branches for different distros/releases/versions (see https://salsa.debian.org/kernel-team/linux/-/branches for an example 👀).

[crazy-max]

Agree with @tianon that it should live in a central repository like this one.

For specs/rules I just push credential-helpers package for testing in this repo. More info: #6

[thaJeztah]

Wearing my Debian hat, I would 100% recommend keeping packaging in a separate repository. The tooling builds with it in the same repository, but it's not typically maintained that way, especially since packagers can very rarely use much if any of the upstream packaging bits and because they often have to maintain different branches for different distros/releases/versions (see https://salsa.debian.org/kernel-team/linux/-/branches for an example 👀).

Thanks for looking, that's definitely useful input!

At times it's somewhat hard to decipher what the intent / convention is, because much of the documentation around deb and rpm packages is written with "distros" in mind, and I found passages describing "put a debian directory at the root of the source code, with <these files> in it, so I started to wonder if that's what's "expected" to be the case.

So, mostly trying to figure out "where" to make the split between responsibilities of the "project" and "packaging" (where to put the boundary). I agree that things related purely to (distro-specific) packaging would best live outside of the project.

I guess the concern I had was that some knowledge about "what's needed to build" may lie with the maintainers of the project, and potentially missed during packaging (hopefully things just fail hard, which is the ideal situation). I guess a well maintained PACKAGERS.md would be the solution to that (but realistically, those can get out of date easily).