rpkg

#530 add base of spec preprocessing functionality
Closed by onosek. Opened by clime.
clime/rpkg master  into  master

Download 530.patch

Hello,

this pull request enables spec preprocessing functionality that originated in rpkg-util. I tested this PR successfully with fedpkg tool. I haven't yet tested other tools like rfpkg but I assume they could work if they work in similar fashion to fedpkg. This complements work that was done in mock previously: https://github.com/rpm-software-management/mock/commit/bda814a743ef74e6dfbee261a4db6e2f219382d1

If this is accepted, I plan to continue the integration by extending the tag subcommand to be able to populate tag messages automatically from git commits from the latest reachable annotated tag and also add some more options (like --name, --version, or --release and possibly others to make the integration smooth).

Basically, what this commit does is that it enables usage of rpkg-macros in spec files (if preprocess_spec configuration option is set to True). This is a possible solution for automatic release and changelog generation problem but it offers more than that.

I am open to any required code changes and improvements in this PR or in future.

NOTES from the commit:

  • enabled by setting preprocess_spec to True in the config file
  • uses preproc and rpkg-macros to do the job
  • when preprocessing is enabled, the generated files will
    be put into an auto-generated directory under /tmp/
    (e.g. /tmp/fedpkg for the fedpkg tool)
  • this enables preprocessing for all rpm-based commands:
    srpm, local, prep, install, compile, lint, verify-files, clog
    mockbuild, koji scratch build, copr build
  • also a new subcommand spec is introduced just to render
    the spec file without further building srpm etc.
  • some introduced functions are currently unused (e.g.
    utils.changelog_entry or utils.edit). The functions are
    intended to be used in a future commit that extends the
    tag subcommand to automatically pregenerate tag messages.
  • preproc and rpkg-macros packages are newly required,
    also python-munch

Signed-off-by: clime clime@fedoraproject.org

2 new commits added

  • fix macro_helper_cmd for python versions < 3.5
  • fix return value from _final_spec when no_regenerate and spec file exists

Pushed some small fixes. But not sure if it helps with the jenkins CI. There seems to be also some other import problem (from pyrpkg import layout).

rebased onto 2777480f15e7768f60c33b6f38e099516857a9f1

pretty please pagure-ci rebuild

4 new commits added

  • add support for verrel command
  • fix macro_helper_cmd for python versions < 3.5
  • fix return value from _final_spec when no_regenerate and spec file exists
  • add base of spec preprocessing functionality

I am looking at the request. It is an interesting set of features. Currently, I am most concerned about the new dependencies.
Together with fedpkg am maintaining also the internal tool rhpkg and I am trying to keep both tools similar as much as possible. And providing comparable features. This approach would require me to maintain additional packages, that are already prepared in Fedora/koji (preproc, rpkg-macros, python-munch) for building rhpkg on the internal side. At least these direct dependencies.
Understand, that at least rpkg-macros and preproc are essential for the request.
Before I will go deeper into the review, I have to decide on this dilemma :).

init.py is getting larger and larger. I understand that it is probably correct to place functionality there, but would it be possible to think about separating it into a different module? Just exploring possibilities regarding this.

What improvements does this change enable?
Looking at rpkg-util repo, it seems to me this change is simplifying life for people who want to manage spec file outside of dist-git. However that is against Fedora packaging guidelines, which want dist-git to be the canonical location for packaging information IIRC.

@onosek yes, preproc, rpkg-macros, python-munch are needed. I can add you as a maintainer of the first two if needed.

We can place the code to a separate module, yes. I was thinking about it when I was writing this PR but waited for feedback first.

@lsedlar: This change enables automatic versioning, changelog and source generation based on git (meta)data. Something which is useful no matter where the spec file is placed. It tries to address problems that lead people to maintaining spec files outside of Fedora.
Edited by clime

In the past days, I was thinking about it more. I am worried about the increased complexity of the code and package maintenance itself. But there is also an argument for not placing this into rpkg. I found that this feature was presented to Fedora committee and eventually rejected. It means I would have to prevent fedpkg (as a big rpkg's "customer") from using this functionality. And this, as per my opinion, considerably lowers benefits having it here.
I appreciate that you must have invested a lot of time and effort into this :-/. I am sorry, I decided to close the PR.

Pull-Request has been closed by onosek
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.