robojerk
45c124637b
Some checks failed
Comprehensive CI/CD Pipeline / Build and Test (push) Failing after 2m1s
Comprehensive CI/CD Pipeline / Security Audit (push) Successful in 46s
Comprehensive CI/CD Pipeline / Package Validation (push) Successful in 1m7s
Comprehensive CI/CD Pipeline / Status Report (push) Has been skipped
195 lines
6.6 KiB
Markdown
195 lines
6.6 KiB
Markdown
# 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](https://packages.fedoraproject.org/pkgs/createrepo_c/createrepo_c/), 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:
|
|
|
|
```bash
|
|
$ 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:
|
|
|
|
```bash
|
|
# 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.
|