On 12/17/20 11:05 AM, Ben Cotton wrote:
>
https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
>
>
> == Summary ==
> This change should enable an opt-in spec file preprocessor in Fedora
> infrastructure for the benefit of packagers. The preprocessor allows
> some very neat tricks that were impossible before, for example
> generate changelog and release automatically from git metadata or pack
> the entire dist-git repository into an rpm-source tarball (effectively
> allowing unpacked repos to live in DistGit).
>
> == Owner ==
> * Name: [[User:clime| Michal Novotný]]
> * Email: clime(a)fedoraproject.org
>
>
> == Detailed Description ==
>
> There is a recently added feature into mock:
> [
https://github.com/rpm-software-management/mock/wiki/Plugin
> -rpkg-preprocessor
> the rpkg preprocessor] which, if enabled, introduces an intermediate
> step just before srpm building. This step consists of running the spec
> file through a text preprocessing engine that includes an already
> present library of macros designed specifically for rpm spec file
> generation from git metadata. This library is called
> [
https://docs.pagure.org/rpkg-util/v3/macro_reference.html
> rpkg-macros]. The macros there allow packagers to have their
> `%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
> automatically generated from dist-git repository data and metadata.
> The library can be easily extended in future to support more packager
> use-cases or even a completely new library can be developed that
> doesn't look at git metadata at all and instead, for example, analyses
> already present tarball content to render spec file based on upstream
> information. This doesn't mean it will happen but the framework is
> generic enough to support that. There is also support for user-defined
> macros that are loaded on-demand from a file placed alongside the
> package sources, maintained by packager. This feature wouldn't be
> enabled by this change from start but it's an example of freedom that
> the preprocessing framework is able to provide. Enabling this change
> should be very easy, basically adding:
>
> <pre>
> config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
> </pre>
>
> into mock configuration of Koji builders and using at least mock 2.7.
> Some very minor change may be also needed in Koji regarding the spec
> file lookup.
>
> Even if the change is enabled on the infrastructure level like this,
> the packager will still need to opt-in to use the preprocessor. The
> opting-in is done by placing `rpkg.conf` file into the package
> top-level directory with the following content:
>
> <pre>
> [rpkg]
> preprocess_spec = True
> </pre>
>
> When this is done by a packager, the preprocessor will be finally
> enabled for the given package.
>
> Alongside, there is an ongoing work to add the preprocessor support
> into the `rpkg` python library so that a packager can easily work with
> the spec files containing the preprocessor (rpkg) macros:
>
https://pagure.io/rpkg/pull-request/530
>
>
Is this pull request needed so that the preprocessor will run if I do
`fedpkg mockbuild` or does fedpkg already do this if the preprocessor is
enabled?
The pull request is needed for it. fedpkg doesn't currently have support
for preprocessing.
Cheers
clime
-Tom
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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.or
g/archives/list/devel(a)lists.fedoraproject.org