Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Where should things live?

Aperta
#3 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Ambito
build-system, release

Direzione di ricerca

Inizia esaminando le due posizioni proposte nell'issue per le specifiche e le regole deb/rpm, includendo i pro e i contro elencati e l'esempio di pacchettizzazione di containerd collegato. Il lavoro è completo quando è stata presa e documentata una decisione sulla responsabilità del repository, sulle tempistiche degli aggiornamenti, sui test, sulla copertura delle distribuzioni e su come verranno comunicati i cambiamenti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Dockerfile
Stelle
35
Fork
38
Merge medio
1g 18h
PR unite (30g)
14

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di docker/packaging

Tutte le issue di docker/packaging

Issue simili

Altre issue su Build System

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.