Open thaJeztah opened 2 years ago
/cc @crazy-max @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 :eyes:).
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: https://github.com/docker/packaging/pull/6
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).
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
deb/rpm specs and rules in a central repository
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