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

[RFC] Update-specific messages, and install-only INSTALL.msg

Aperta
  • Qualcosa non va?
#559 1 commento 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
Stack tecnologico
c
Ambito
cli

Direzione di ricerca

Start by tracing how INSTALL.msg is created and displayed, then inspect the xbps-create invocation and xbps-src package layout described in the issue. Determine how versioned UPDATE-.msg files could be stored and selected for update transactions, while keeping INSTALL.msg limited to fresh installs and reinstalls. Done means the behavior and required package changes are specified well enough to implement and test.

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

Descrizione

As is currently stands, the only way to signal a breaking change in an update is to mention it in INSTALL.msg. This shows the message for any updates, and even for fresh installations. On top of that, messages relevant to only a fresh installation are shown for updates too.

The result is that most messages shown in an average transaction aren't relevant in any way to the transaction, which causes users to learn to tune out the messages.

I propose adding messages that are specific to an update (or rather, specific to a breaking change), and changing the existing INSTALL.msg to be only shown for fresh installs or reinstalls.

This would require storage of the update messages, along with the package version containing the breaking change. One such update message would only be shown if the package is being updated, and if the currently installed version is lower than the message's version. XBPS should be able to show as many update messages as relevant to a particular transaction.

The logic for when INSTALL.msg is shown would be changed to not show the message for updates.

I'm not familiar enough with XBPS internals to know what would need to change implementation-wise.

On xbps-src's end this would probably look like additional UPDATE-<ver>.msg files in a package's directory, along with changes in the xbps-create invocation. A good number of packages would need to be updated to use UPDATE messages.

EDIT: I realised a big flaw in my pick of what version should be recorded along with an UPDATE message, so I switched it to be the first version that breaks (message shows for any currently installed version lower than it).

Lingua principale
C
Stelle
1.2k
Fork
152
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

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 void-linux/xbps

Tutte le issue di void-linux/xbps

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.