Simplifying Package Submission Progress (8 July – 15 July) – GSoC ’25

News & Announcements Community Blog
1

Originally published at: Simplifying Package Submission Progress (8 July – 15 July) – GSoC ’25 – Fedora Community Blog

Hi, I am Mayank Singh, welcome back to this blog series on the progress of the new package submission prototype, if you aren’t familiar with the project, feel free to check out the previous blogpost here.

Event Handling, Forgejo Support, and Source Management (July 8 – July 15)

This week was focused on the service’s forge and tackling the challenge of source management.

Migrating to Forgejo and Handling Events

Based on community feedback, advantages and assessing our requirements, I moved the service’s forge to Forgejo. This minimal, open-source alternative to GitHub and GitLab is simpler to self-host and has significantly smoothed out our testing process.

On the implementation front, I added support for parsing issue and push events in packit-service, which allow to support parsing commands from issue comments. That being done adding support for pull_request is only trivial now and have a solid understanding of packit-service‘s event model to trigger task execution.

Package Source Handling

I hit a technical dilemma when considering handling the case of packages with new dependencies in a single Pull Request and handle their sources. The workflow requires accessing the PR’s diff, resolving it into individual files, and submitting those sources to be built in COPR.

My initial solution to this problem was to create a dedicated organization in Forgejo where every new package would get its own repository to store its sources. However, my mentor advised against this model, we discussed and realized it would become too complex and non-intuitive to work with. Instead, he clarified the path forward to focus on simple packages for now and investigate how Packit already solves this by cloning the source repository.

What’s Next?

  • Enhancing Forgejo Integration: Implementing methods to allow the service to post comments and add reactions on Forgejo.
  • Implementing Source Fetching: Building the logic to fetch source files from Pull Requests for package builds.
  • Expanding Commands: Adding new commands and tasks to support this workflow.

Stay tuned, more things to share next week 🙂

2

Not sure if this is the right place, but it seems that for the new package submission process, you’re looking into packit and possible source-git also. So it might be a good opportunity to revisit some design decisions.

For new “packagers” which are not yet in the packagers’ group, our dist-git layout is often a challenge: the sources file is a mystery at first, and once you know what it is, you still cannot upload the actual sources to lookaside-cache.

packit (in one variant) and source-git put information into the upstream source repo (or a fork), which creates its own challenges. (For example, you mix spec and upstream git history.)

I’ve had great results with a layout which mimicks our dist-git. In short, instead of the file sources which tracks checksums, I use a git repo containing spec and patches as usual and a submodule source (for a single source) or submodules in a directory sources (for multiple ones): they can point directly at upstream’s git repo, and just like dist-git’s sources file tracks a checksum, git’s submodules track a sopecific object ID (git hash) for upstream’s repo. (Technically, I use rpkg to make this work.)

For newcomers, this means they can create a lean repo containing just the spec and a submodule pointing to upstream’s git repo, all using “standard” tools. Testing merely requires rpkg or such, no Fedora packager setup.

1 Like