-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs > > == 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 == > * Name: [[User:nim| Nicolas Mailhot]] > * Email: <nicolas.mailhot at laposte.net> > > == Detailed Description == > > This is a system-wide change 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 it was foolish to depend > on rpmbuild to parse Tags in anything except canonical order. I think this would be already at least 30 times we mentioned that RPM works as expected and the bug was just in the spec files that relied on Name being parsed before expanding ~/.rpmmacros. > === Forge === > > * forge macro now process patches, including in multi-source spec > files, in a natural way > * 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 > * zero suffix is no longer special (à la Source/Source0 way), you can > declare forge blocks starting at 42 if that‘s your preference > > === Fully automated packaging === > > A 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. RPM upstream is working on generated subpackages, how does it play with this black magic? > Such a framework is a requirement to control the generation order > within the spec file and make sure rpm maintainers are not cross with > you. > > 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. So essentially you are saying that we should not use RPM preamble. Did you talk to upstream about this idea? > A packager that needs custom processing can add custom code above or > bellow the various `%auto_foo` calls, and check with `rpmspec -P` > that > the result does what he wants it to do. For obvious reliability > reasons injecting custom code in the middle of an `%auto_foo` > sequence > is not allowed. What about rpmdev-bumpspec, vim plugin and such tools adoption that expect Version/Release/%changelog to be present in spec? > <pre> > %global source_name … > %global source_release … > %global source_post_release … > > %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 > </pre> > > === 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 === > > Writing high-level features like the above required defining a > library > of lua routines like an expand that expands fully, an unset that > actually undefines, a read that tells you if a variable exists or is > set to "", a `fedora.echo()` wrapper around > `rpm.expand("%{echo:%{expand:" .. text .. "}}")`, etc. Those are now > available for others to use should they want to. > > My coding skills are not up to navigating the upstream low level rpm > lua API without blowing up on the landmines it is littered with. > Therefore, I abstracted landmine avoidance in a single place. > > === 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). > > == 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. So this came out of sudden, without any discussion with RPM upstream. What about integration with Rust, Python, Ruby and Java ecosystems? Is it planned for the future? Having something very generic, unmaintainable and overcomplicated just for Go and Fonts does not make much sense to me. > == 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. > > * Release engineering: https://pagure.io/releng/issue/9565 > > * FPC: https://pagure.io/packaging-committee/issue/997 > > * 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) > <!-- If your Change may require trademark approval (for example, if > it > is a new Spin), file a ticket ( https://fedorahosted.org/council/ ) > requesting trademark approval from the Fedora Council. This approval > will be done via the Council's consensus-based process. --> > > == Upgrade/compatibility impact == > > This is a pure build tooling update, it changes how things are built > not what is built. This is not fully true, this will make those packages non-buildable on older, supported, Fedora releases. > == 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/ I think it would be useful to put concrete examples on the wiki page. > == 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/were envisioned for F33 or F34 will be postponed indefinitely. Again, if this blows up, we need to know what needs to be reverted, when and who will do that. > == 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 > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > _______________________________________________ > packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to > packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx - -- Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77lkMACgkQEV1auJxc Hh7l0w//R7l3T+bmLFdAs33lvIa5La78suJeCV86aLR9Kr8xOjdak43egAx9IPDm Mi5tX9+lQhhuRQ7krhIJk410Pn+CshbmIEeLaU8D15eNxmJ683MJnGqy5iwVc6lW dLo7H9BLnvJpgMLzdFS3HAtqHU0ARsKufWGJ1o1g7KMqj/tLZw2YndBUgAaoP5Wx OfZzy9z/iNbhy3PXK0whc6MWw2xHVRgOoLFe356BwKpQ7P9C7/JbqMar1moeuj0A BUxns5X3xXjKIsIHTUlbHNQi1r5FhJdOPpZTFMIquxsURXvlLCP5trnwzj9G/M3O skan0oUYMkQ1vERAAQwAS9V/C75wHasDY1UrcBYA6rMDJcr0JPRSbeV11IPXlivX n2nrz8odSxqG2YvvHuqoqPdKsj+OBRYj6mhlAtuGT6eGvKt4QkabRGRk/TW8rDYh RR6fwVOPJHQ39V+pUWQl3YLxxNb3Jho7fYAfOlj/omyuv1+S2wFZ7jScQc0ApGcw WvLqRGg8P2vKZYFHE7MrtMg/Fj4pNZv5drgMQMkE5ECEVwvyDV/6sjcHF+3H1eEN qrdjmS1L7eCbtKU+zOhiqbIUtD92EKbV3H65tHb/V6LuRRTMcBWHLEpmb0Hy9k26 bXIOu1KY9rUzJArWydQY+A7tgMKP8mT9IhmjiirqF8R1LwPXl2M= =YhtE -----END PGP SIGNATURE----- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
