Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 1 addition & 11 deletions .github/workflows/docker-image.yml
Original file line number Diff line number Diff line change
Expand Up @@ -20,17 +20,7 @@ jobs:
run: dnf -y update fedora-gpg-keys

- name: Install git and Python libraries
run: |
dnf -y install \
git-core \
python3-flake8 \
python3-jinja2 \
python3-koji \
python3-libdnf5 \
python3-pip \
python3-pytest \
python3-pytest-cov \
python3-yaml
run: dnf -y install git-core python3-yaml python3-jinja2 python3-koji python3-pytest python3-flake8 python3-dnf

- name: Clean up
run: dnf clean all
Expand Down
7 changes: 3 additions & 4 deletions .github/workflows/fork-only-workflow.yml
Original file line number Diff line number Diff line change
Expand Up @@ -33,13 +33,12 @@ jobs:
run: |
dnf -y install \
git \
python3-flake8 \
python3-jinja2 \
python3-koji \
python3-libdnf5 \
python3-yaml \
python3-dnf \
python3-pytest \
python3-pytest-cov \
python3-yaml
python3-flake8

- name: Clean up
run: dnf clean all
Expand Down
13 changes: 2 additions & 11 deletions Dockerfile
Original file line number Diff line number Diff line change
@@ -1,16 +1,7 @@
FROM registry.fedoraproject.org/fedora:44

RUN dnf -y update fedora-gpg-keys \
--setopt=tsflags=nodocs \
--setopt=install_weak_deps=False && \
dnf -y install \
git \
python3-jinja2 \
python3-koji \
python3-libdnf5 \
python3-yaml \
--setopt=tsflags=nodocs \
--setopt=install_weak_deps=False && \
RUN dnf -y update fedora-gpg-keys && \
dnf -y install git python3-jinja2 python3-koji python3-yaml python3-dnf && \
dnf clean all && \
rm -rf /var/cache/dnf

Expand Down
84 changes: 1 addition & 83 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,6 @@
# Content Resolver

[![Content Resolver CI](https://github.com/fedora-eln/content-resolver/actions/workflows/docker-image.yml/badge.svg)](https://github.com/fedora-eln/content-resolver/actions/workflows/docker-image.yml)

Content Resolver makes it easy to define and inspect package sets of RPM-based Linux distributions.
Content Resolver makes it easy to define and inspect package sets of RPM-based Linux distribution.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Fix the product description grammar.

Line 3 uses “package sets of RPM-based Linux distribution” without an article. Use the plural form for consistency with “package sets.”

Proposed wording
-Content Resolver makes it easy to define and inspect package sets of RPM-based Linux distribution.
+Content Resolver makes it easy to define and inspect package sets for RPM-based Linux distributions.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
Content Resolver makes it easy to define and inspect package sets of RPM-based Linux distribution.
Content Resolver makes it easy to define and inspect package sets for RPM-based Linux distributions.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@README.md` at line 3, Update the product description sentence in README.md to
use the plural form “RPM-based Linux distributions” so it agrees with “package
sets.”


You define what packages you need, and Content Resolver gives you the whole picture including all the dependencies. And it keeps it up-to-date as packages get updated over time.

Expand All @@ -14,28 +12,6 @@ Content Resolver also helps with minimisation efforts by showing detailed depend

## Using Content Resolver

### Code Structure

Core functionality

```
content-resolver/
├── content_resolver/
│ ├── analyzer.py # Core resolution engine (DNF5)
│ ├── config_manager.py # YAML config loading
│ ├── data_generation.py # Generate non HTML output
│ ├── exceptions.py # Custom exceptions
│ ├── history_data.py # Handle history for graph generation
│ ├── page_generation.py # Generate HTML output
│ ├── query.py # Internal data query mechanism
│ └── utils.py # Helper functions
├── templates/ # Jinja2 HTML templates
├── test_configs/ # Test configurations
├── content_resolver.py # Main entry point
└── refresh.sh # Production deployment script
```


### Controlling Content Resolver

Content Resolver is entirely controlled by a set of YAML files stored in a git repository. Changes to the content can easily be modified and reviewed via pull requests.
Expand Down Expand Up @@ -168,61 +144,3 @@ $ docker run --rm -it --tmpfs /dnf_cachedir -v $(pwd):/workspace content-resolve
```

The output will be generated in the `output` directory. Open the `output/index.html` in your web browser of choice to see the result.

### Resolution Process

**Phase 1: Repository Analysis**
```
For each repository and architecture:
1. Create DNF5 Base with repository configuration
2. Apply repository priorities (1=highest)
3. Apply package exclude lists (e.g., rust-*-devel, golang-*-devel)
4. Load repository metadata
5. Query all available packages
6. Deduplicate by NEVRA (Name-Epoch:Version-Release.Arch)
7. Track which repo provides each package
```

**Phase 2: Environment Resolution**
```
For each environment:
1. Create DNF5 Goal with environment packages
2. Resolve dependencies using DNF5 transaction
3. Check transaction.get_problems() for conflicts
4. Extract installed packages (base environment)
5. Build package relationship graph
```

**Phase 3: Workload Resolution**
```
For each workload on top of each environment:
1. Load base environment packages
2. Add workload-specific packages to Goal
3. Resolve additional dependencies
4. Separate environment packages from added packages
5. Track which workloads require which packages
```

**Phase 4: Buildroot Resolution** (for views with `buildroot_strategy: root_logs`)
```
For each source package in the view:
1. Download Koji root.log via Koji API
2. Parse build dependencies from root log
3. Create fake workload with build dependencies
4. Resolve buildroot on top of build group
5. Track buildroot packages separately from runtime
6. Iterate until all transitive build deps resolved
```

### Repository Priority System

Repositories are assigned priorities (1=highest, 5=lowest) to control package selection when multiple versions exist:

```yaml
BaseOS: priority: 1 # Prefer packages from BaseOS
AppStream: priority: 1 # Prefer packages from AppStream
CRB: priority: 1 # CodeReady Builder
Extras: priority: 3 # Additional packages
buildroot: priority: 4 # Build-time only packages
Rawhide: priority: 5 # Fallback for missing packages
```
Loading