[Feature]: enhance patch-add with strip-aware application and render-time diagnostics

Aperta
  • Qualcosa non va?
#423 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
build-system, tooling

Direzione di ricerca

Start by locating the patch-add overlay handling, both spec editors, and the render-time diagnostics and tests. Trace how overlays are applied and how the final spec is rendered before planning changes. Done means both editors follow the requested strip rules, render warns without failing when application is missing or unclear, and tests cover edits, warnings, prepared-source changes, schema, documentation, skills, and fingerprints.

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

Descrizione

enhancement

Is your feature request related to a problem? Please describe.

patch-add copies a patch into component sources and registers it through a PatchN: tag or %patchlist. Registration does not establish whether %prep actually applies the patch or uses a compatible strip level.

This enhancement addresses #408 and #409:

  • Explicit patch declaration cannot guarantee an added patch applied.
  • Bulk application can use an incompatible strip setting, causing a failure only during the build.
  • Workarounds require guessing allocated patch numbers and maintaining fragile spec-search-replace anchors.

Describe the solution you'd like

Add an optional strip field to patch-add, with conservative automatic application and final-render diagnostics. Support the same policy in the default legacy editor and experimental structural editor.

[[components.expat.overlays]]
type = "patch-add"
source = "patches/fix.patch"
strip = 1
Handle the simple cases automatically

Here, S means the requested strip level.

Spec situation Automatic behavior
An existing %autosetup, %autopatch, %forgeautosetup, or patch-applying %goprep already applies the new patch at the right strip level Leave the application commands unchanged. Do not add a second command for the same patch.
A simple sequence of individual %patch commands Add the command for the new patch after the sequence.
Setup-only preparation, including %autosetup -N, %forgeautosetup -N, or a setup-only %goprep Add a separate application command when the source directory and placement are clear. Preserve the selected backend; use a selected %autopatch call rather than plain %patch where necessary.
An %autopatch range that leaves out the new patch e.g. %autopatch -M99 does not apply patch 100. Add a separate command when there is one clear place for it.
Bare %autosetup, %autopatch, or %forgeautosetup, with no existing patches Add the requested -pS setting when all new patches need the same strip level.
Simple setup-only %goprep, with no existing patches It can receive -pS to enable automatic application instead of adding a separate command, when all new patches need the same strip level.

Use the patch number azldev actually assigns, so users do not have to guess it. Keep patches in overlay order and account for all new patches before changing a shared strip setting.

Different patches should be able to use different strip levels in a simple explicit sequence. For example:

Patch10: first.patch
Patch11: second.patch

%prep
%setup -q
# Existing patch sequence remains in place.
%patch -P10 -p1
%patch -P11 -p2

Retain the existing setup options and patching method. For example, a spec using the Git backend should use selected %autopatch calls rather than switch to plain %patch.

Warn instead of guessing in complicated cases

The implementation should not try to rewrite every possible %prep script. Register the patch, but leave application commands unchanged and warn when:

Warning case When to warn
Strip-level mismatch An existing command would apply the patch with a different strip level.
Risk to existing patches Changing a shared strip setting could affect existing patches; Supporting different strip levels would require splitting or disabling automatic patch application.
Multiple working directories The spec patches files in different directories, such as NSS.
Conditional patch application The spec applies patches differently in conditional branches, such as Glycin.
Unclear patch selection Macros or generated patch numbers make it unclear which command applies the patch.

Check actual command options: %autosetup -N does not apply patches, and %autopatch -M99 does not apply patch 100. Do not mistake comments or macro-definition bodies for application commands. Keep %patchlist support where application is clear.

Do not apply a patch twice, move it into the wrong directory or branch, or put it after preparation steps that need the patched files. If the right place is unclear, a warning is better than a guessed edit.

Warn even when strip is not set

Without strip, keep today's behavior: copy and declare the patch, but do not add application commands or guess a strip level.

Still warn during render if no recognized command applies the added patch. This check must run whether or not strip is set. Also warn if application is unclear or the patch's paths suggest a strip-level problem. Missing -p alone is not proof of a problem; defaults depend on the patching method.

Check the final spec after all overlays, since a later overlay may add the application command or fix its options. Include the component, patch file and number when known, and the reason for the warning.

[
  {
    "component": "mypackage",
    "outputDir": "specs/m/mypackage",
    "status": "ok",
    "changed": true,
    "patchWarnings": [
      {
        "code": "application-unverified",
        "filename": "fix-build-flags.patch",
        "patchNumber": 0,
        "spec": "mypackage.spec",
        "line": 12,
        "reason": "no recognized command in '%prep' applies this patch; add an explicit application command"
      }
    ]
  }
]

Render should succeed with these warnings. They are not a guarantee that the patch applies: render does not execute %prep. Invalid configuration or a failed parse/edit should still be an error.

Allow strip = 0, reject negative values, and reject strip on overlay types other than patch-add.

Both parsers and tests

Use the same rules for the default legacy parser and the experimental structural parser. Tests should cover the simple edits, different strip levels, and warning-only cases, including omitted strip and later overlays that fix application. Failed edits must not leave partial changes.

Include tests that show the patch actually changes the prepared source, not just that its declaration exists. Update the overlay documentation, generated schema, and emitted agent skills, and make sure changing strip changes the component fingerprint.

Describe alternatives you've considered

Adding both apply and strip would work, but strip alone is enough to ask for automatic application. Always adding %patch commands or changing every spec to -p1 could break existing patches.

Keep spec-search-replace available for complex cases. More advanced automatic rewriting can come later.

Use case / impact

This makes downstream patches easier to add without guessing patch numbers. It also catches missing application during render, even for existing overlays that do not set strip, instead of letting a build succeed without the intended fix.

azldev version

v1.1.0

Additional context

Examples from Azure Linux:

  • OpenSC uses individual patch commands.
  • Expat uses bare %autosetup.
  • NSS applies patches in different directories.
  • Glycin applies different patch sets depending on the build options.
Lingua principale
Go
Stelle
18
Fork
30
Merge medio
3g 17h
PR unite (30g)
40

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 microsoft/azure-linux-dev-tools

Tutte le issue di microsoft/azure-linux-dev-tools

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.