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

Đang mở
  • Có gì không ổn?
#423 3 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 4 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
build-system, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Go
Star
18
Fork
30
Merge trung bình
3 ngày 17 giờ
Pull request đã merge (30 ngày)
40

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/azure-linux-dev-tools

Tất cả issue của microsoft/azure-linux-dev-tools

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.