New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Where should things live? #3
Comments
/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 👀). |
Agree with @tianon that it should live in a central repository like this one. For specs/rules I just push |
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 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 |
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
The text was updated successfully, but these errors were encountered: