From Fedora Project Wiki

< Changes

Revision as of 14:10, 30 June 2020 by Nim (talk | contribs) (Created page with "= Patches in forge, auto macros, detached changelog = == Summary == redhat-rpm-config will be updated to add patching support to forge macros, a plug-able framework to regis...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Patches in forge, auto macros, detached changelog

Summary

redhat-rpm-config will be updated to add patching support to forge macros, a plug-able framework to register macros to execute in specific sections, and rpm changelogs in detached files.

Owner

  • Email: <nicolas.mailhot at laposte.net>

Current status

  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The change is market as system-wide because all packages build with redhat-rpm-config, but it only concerns packages that opted to use this part of redhat-rpm-config (users of forge, fonts and go macros).

It was driven first, by the need to make the underlying macro infrastructure robust enough to package Go modules, and second, by an unfortunate rpm 4.15 regression that proved the rpm parser could not be relied upon to parse rpm preamble declarations except in a very specific order.

Visible features:

=== Forge

1. forge macro now process patches, including in multi-source spec files, in a natural way 2. all dependencies on source/patch numbering were eradicated, you can write a whole multi-source/multi-patch spec without worrying about source or patch numbers 3. zéro suffix is no longer special (à la Source/Source0 way), you can declare forge blocks starting at 42 if that‘s your preference

=== Automated packaging

An framework was added so macro subsystems can register execution blocks in specific parts or the spec file. Execution blocks are orchestrated (using KISS rules) so for example the forge part of prep is executed before the go parts that depend on forge archives being unpacked and patched, and macros that want to create srpm headers are executed before macros that want to create subpackage headers

That means a spec with no special custom processing is reduced to a set of %global control variables that activate specific execution blocks, and everything bellow those control variable is short and unchanging boilerplate.

` %global source_summary …

%global forge_url0 … %global forge_commit0 …

%global forge_url1 … %global forge_tag1 …

%global go_module33 … %global go_description33 …

%global font_family22 … %global font_conf22 …

%auto_init %auto_pkg

%sourcelist %auto_sources

%patchlist %auto_patches

%prep %auto_prep

%generate_buildrequires %auto_generate_buildrequires

%build %auto_build

%install %auto_install

%check %auto_check

%auto_files

%changelog %auto_changelog `

=== Detached changelogs

This framework was used to implement detached rpm changelogs in a reliable way.

=== Generic -doc creation

This framework was used to implement automated -doc subpackage creation, because creating them by hand gets annoying after the nth upstream that wants you do distribute heavy PDF documentation files.

== Huge refactoring and fleshing out of the lua library

Because writing high-level features like the above was easier with an expand that expands fully, an undefine that actually undefines, a fedora.echo() wrapper around rpm.expand(%{:echo:%{expand:}}), etc

== Drawbacks

Nothing is free, and a higher level of automation required using rigid naming for control variables. Because software is a lot less tolerant of fuzzy naming than human beings.

So, all forge control variables are renamed, fonts control variables have been renamed too, and go control variables will need renaming (in that last case, that’s not a problem because moving to go modules requires reworking variables anyway, so it will be done as part of the module effort in F34).

To ease the transition a compatibility layer was added to forge macros so old variables and new variables are aliased both ways (this will eventually go away because it’s quite a lot of compatibility code to maintain). Mixing syntaxes (old and new) is not supported, you need to convert your spec file to new forge variables or not at all (if not at all, do not try to use new features like patching).

Feedback

Benefit to Fedora

Spec files that do more with less manual expensive to maintain spec code.

Without this productivity win, complex efforts like converting Fedora Go packages to Go modules, or draining the Font packages swamp given that legacy formats are no longer supported by apps, are not possible with the current level of Fedora manpower.

Scope

  • Proposal owners:

The core of the feature is done and tested (and retested). It may evolve during the redhat-rpm-config merge process.

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95

  • Other developers:

The way current forge macros call forge macros will need a little patching once the change lands. For other packagers, there should be no change except a warning in rpm build logs to switch to the new syntax before the compatibility layer is removed.

  • Policies and guidelines:

Forge guidelines will need some rework (mostly simplification, because the new syntax is both more powerful and more regular).

For the average packager, the new syntax is the same old syntax with little naming adjustments (for example, %{forgeurl} becomes %{forge_url}, %forgemeta is subsumed into %auto_init, etc)

  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This is a pure build tooling update, it changes how things are built not what is built.

How To Test

A redhat-rpm-config packages with the changes and some example packages are available in

https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/builds/

User Experience

N/A Packager experience change only

Dependencies

The change depends on a redhat-rpm-config merge by redhat-rpm-config maintainers

Contingency Plan

There is no contingency plan because the redhat-rpm-config merge will happen or not. If it does not happen, i18n, fonts and Go Changes that are envisioned for F3 or F34 will be postponed indefinitely.

Documentation

There is as much documentation as the average redhat-rpm-config change (ie comments in the macro files themselves)

Release Notes

N/A Packager productivity change only