deb-mock/FEDORA_DEBIAN_PACKAGING_COMPARISON.md

Fedora vs Debian Packaging Strategy Comparison

Overview

This document compares how Fedora packages mock with multiple binaries versus our deb-mock packaging strategy, highlighting the similarities and differences in approach.

Fedora Mock Packaging Analysis

Package Structure

Based on your research and the Fedora packages, Fedora uses:

1. mock - Core package
2. mock-filesystem - Filesystem layout
3. mock-lvm - LVM support
4. mock-rpmautospec - RPM auto-specification
5. mock-scm - Source Control Management

Key Dependencies

From your dnf repoquery analysis:

$ dnf repoquery --requires mock
/usr/bin/bash
/usr/bin/python3
coreutils
createrepo_c                    # Repository metadata generation
mock-configs
mock-filesystem = 6.1-1.fc42
mock-filesystem = 6.3-1.fc42
pigz
procps-ng
python(abi) = 3.13
python3-backoff
python3-distro
python3-jinja2
python3-pyroute2
python3-requests
python3-rpm
python3-templated-dictionary >= 1.5
shadow-utils
systemd
systemd-container
tar
usermode
util-linux

Dependency Chain Analysis

• createrepo_c → createrepo_c-libs → libmodulemd
• mock-filesystem → shadow-utils (minimal dependencies)

deb-mock Packaging Strategy

Package Structure

Our deb-mock follows a similar modular approach:

1. deb-mock - Core package (equivalent to mock)
2. deb-mock-filesystem - Filesystem layout (equivalent to mock-filesystem)
3. deb-mock-configs - Pre-built configurations (equivalent to mock-configs)
4. deb-mock-plugins - Extended functionality (equivalent to mock-lvm, mock-rpmautospec, mock-scm)
5. deb-mock-dev - Development tools
6. deb-mock-cache - Caching and optimization

Debian Dependencies (Equivalent to Fedora)

Fedora Package	Debian Equivalent	Purpose
createrepo_c	apt-utils	Repository metadata generation
createrepo_c-libs	libapt-pkg-dev	Core library for package management
libmodulemd	python3-apt	Module metadata handling
python3-rpm	python3-apt	Package management bindings
systemd-container	systemd-container	Container management
shadow-utils	shadow-utils	User/group management

Key Differences

1. Repository Management

• Fedora: Uses createrepo_c for RPM repository metadata
• Debian: Uses apt-utils and libapt-pkg-dev for APT repository management

2. Package Management

• Fedora: RPM-based with python3-rpm bindings
• Debian: APT-based with python3-apt bindings

3. Configuration Management

• Fedora: mock-configs package for configurations
• Debian: deb-mock-configs with YAML-based configurations

4. Plugin System

• Fedora: Separate packages for specific functionality (mock-lvm, mock-rpmautospec, mock-scm)
• Debian: Unified deb-mock-plugins package with modular plugin system

Implementation Benefits

1. Modular Installation

Both approaches allow users to install only what they need:

# Fedora - Minimal installation
dnf install mock mock-filesystem

# Debian - Minimal installation  
apt install deb-mock deb-mock-filesystem

# Fedora - Full installation
dnf install mock mock-filesystem mock-lvm mock-rpmautospec mock-scm

# Debian - Full installation
apt install deb-mock deb-mock-filesystem deb-mock-configs deb-mock-plugins deb-mock-cache

2. Dependency Management

Both systems provide clear dependency relationships:

• Core packages have minimal dependencies
• Optional packages depend on core packages
• Development packages are separate from runtime

3. Security Benefits

• Reduced attack surface with minimal base installation
• Optional components can be disabled if not needed
• Clear separation of concerns

File Organization Comparison

Fedora Structure

mock/
├── mock/                    # Core package
├── mock-filesystem/         # Filesystem package
├── mock-lvm/               # LVM package
├── mock-rpmautospec/       # RPM auto-spec package
└── mock-scm/               # SCM package

Debian Structure

deb-mock/
├── deb-mock/               # Core package
├── deb-mock-filesystem/    # Filesystem package
├── deb-mock-configs/       # Configuration package
├── deb-mock-plugins/       # Plugin package
├── deb-mock-dev/           # Development package
└── deb-mock-cache/         # Cache package

Build System Integration

Fedora (RPM)

• Uses .spec files for package definitions
• %files sections define package contents
• Requires: and Recommends: for dependencies

Debian (DEB)

• Uses debian/control for package definitions
• .install files define package contents
• Depends: and Recommends: for dependencies

Advantages of Our Approach

1. Unified Plugin System

Unlike Fedora's separate packages for each feature, we use a unified plugin system that's more flexible and easier to maintain.

2. YAML Configuration

Our YAML-based configuration system is more human-readable and easier to modify than Fedora's configuration files.

3. Better Integration

Our approach is specifically designed for Debian's ecosystem and integrates better with existing Debian tools.

4. Extensibility

The plugin system allows for easy addition of new functionality without creating new packages.

Migration Path

For Existing Users

1. Automatic Migration: Core package pulls in essential subpackages
2. Gradual Migration: Users can install additional packages as needed
3. Backward Compatibility: All functionality remains available

For New Users

1. Minimal Installation: Install only core package
2. Add Components: Install subpackages as needed
3. Full Installation: Install all packages for complete functionality

Conclusion

Our deb-mock packaging strategy successfully mirrors Fedora's successful multi-package approach while being optimized for Debian's ecosystem. The key advantages are:

1. Modular Design: Users install only what they need
2. Clear Dependencies: Well-defined package relationships
3. Security Benefits: Reduced attack surface
4. Maintainability: Easier to maintain and update
5. Extensibility: Easy to add new functionality

This approach provides a solid foundation for deb-mock to become a production-ready tool that can compete with Fedora's mock while being perfectly suited for Debian-based systems.