coreos / coreos/chunkah

Group packages that consistently update together

Open
#151 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Rust
Stars
145
Forks
15
Avg merge
8m
Merged PRs (30d)
3

Description

In many images, there are natural groupings of packages that almost always update together; for example, on Fedora Kinoite, there's the qt6-* packages, the kf6-* packages, and the KDE Plasma packages (you can see these updating as a group in Bodhi). But Chunkah doesn't do anything special to group these together (and these are higher-level groupings than SRPMs), so they tend to end up scattered throughout their stability tier, which is inefficient.

I can think of two approaches to improving this situation:

  • First, we could provide a way to specify package groupings via configuration. That is, there could be an optional "package grouping" file provided at build-time that tells Chunkah to treat a group of packages as a single package: they would always be placed in the same layer, and their stability score would be determined using the union of all their changelog entries.
  • Second, we could attempt to automatically detect package groupings, perhaps using some sort of correlation/clustering analysis on the changelog timestamps.

The first approach has the disadvantage that such configurations would need to be written, tested, and maintained for each image. The second approach has its own difficulty: Any method of automatically detecting groupings would need to be very stable, since any changes in the groupings would have an immediate negative impact on layer reuse.

Perhaps a good approach would be a sort of hybrid of these: If the automatic package grouping algorithm was provided as a separate tool that could generate a config file to be fed into Chunkah, the package grouping configuration wouldn't have to be written by hand, but could still be saved and reused in subsequent builds to avoid stability problems.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files or tests; begin by tracing Chunkah’s package-layer placement and changelog stability handling. Compare the proposed build-time grouping configuration with automatic or hybrid generation, and define done as an agreed, reusable grouping design that preserves stable layer reuse.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
build-system
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.