deb-mock/PACKAGING_STRATEGY.md

deb-mock Packaging Strategy

Overview

This document outlines the packaging strategy for deb-mock, inspired by Fedora's multi-package approach for mock. The goal is to create a modular packaging system that allows users to install only the components they need.

Fedora Mock Packaging Analysis

Current Fedora Structure:

• mock - Core package with main functionality
• mock-filesystem - Filesystem layout and structure
• mock-lvm - LVM support for advanced storage
• mock-rpmautospec - RPM auto-specification features
• mock-scm - Source Control Management integration

Key Dependencies:

• createrepo_c - Repository metadata generation
• createrepo_c-libs - Core library for repository management
• libmodulemd - Module metadata handling
• python3-* - Python dependencies
• systemd-container - Container management

deb-mock Package Structure

Core Packages:

1. deb-mock (Main Package)

• Purpose: Core deb-mock functionality
• Dependencies:
  • python3-click, python3-yaml, python3-jinja2
  • sbuild, schroot, debootstrap
  • systemd-container (equivalent to Fedora's systemd-container)
• Contents:
  • Main deb-mock binary
  • Core Python modules (deb_mock/)
  • Basic configuration files
  • CLI interface

2. deb-mock-filesystem (Filesystem Package)

• Purpose: Filesystem layout and chroot structure
• Dependencies: shadow-utils (minimal, like Fedora)
• Contents:
  • Chroot filesystem templates
  • Directory structure definitions
  • Filesystem configuration files
  • Mount point definitions

3. deb-mock-configs (Configuration Package)

• Purpose: Pre-built configurations for different distributions
• Dependencies: deb-mock
• Contents:
  • Distribution-specific configurations
  • Architecture-specific settings
  • Default build configurations
  • Template configurations

4. deb-mock-plugins (Plugin Package)

• Purpose: Extended functionality through plugins
• Dependencies: deb-mock
• Contents:
  • Built-in plugins (deb_mock/plugins/)
  • Plugin configuration files
  • Plugin documentation
  • Plugin management tools

5. deb-mock-dev (Development Package)

• Purpose: Development tools and headers
• Dependencies: deb-mock
• Contents:
  • Development headers
  • API documentation
  • Plugin development tools
  • Testing utilities

Optional Packages:

6. deb-mock-cache (Caching Package)

• Purpose: Advanced caching and optimization
• Dependencies: deb-mock, ccache
• Contents:
  • Caching plugins
  • Cache management tools
  • Performance optimization utilities

7. deb-mock-ci (CI/CD Package)

• Purpose: CI/CD integration tools
• Dependencies: deb-mock
• Contents:
  • CI/CD integration scripts
  • Automated testing tools
  • Build automation utilities

Debian Package Dependencies

Core Dependencies (equivalent to Fedora):

• apt-utils - APT utilities (equivalent to createrepo_c)
• apt-transport-https - HTTPS transport support
• libapt-pkg-dev - APT development libraries
• python3-apt - Python APT bindings
• systemd-container - Container management
• shadow-utils - User/group management

Build Dependencies:

• build-essential - Essential build tools
• devscripts - Debian development scripts
• debhelper - Debian packaging helper
• dh-python - Python packaging helper
• python3-setuptools - Python setuptools

Implementation Strategy

Phase 1: Core Package Structure

1. Update debian/control for multiple packages
2. Create package-specific directories
3. Implement package separation logic
4. Update build system for multi-package builds

Phase 2: Subpackage Implementation

1. Implement deb-mock-filesystem package
2. Implement deb-mock-configs package
3. Implement deb-mock-plugins package
4. Test package separation and dependencies

Phase 3: Advanced Packages

1. Implement deb-mock-cache package
2. Implement deb-mock-ci package
3. Add optional dependencies
4. Create package documentation

Benefits of Multi-Package Approach

1. Modular Installation

• Users install only what they need
• Reduced attack surface
• Smaller base installation

2. Better Dependency Management

• Clear dependency relationships
• Easier maintenance
• Reduced conflicts

3. Enhanced Security

• Minimal base package
• Optional components
• Better isolation

4. Improved Performance

• Faster installation
• Reduced memory footprint
• Better caching

Migration Strategy

For Existing Users:

1. Automatic Migration: deb-mock package pulls in all subpackages
2. Gradual Migration: Users can remove unwanted subpackages
3. Backward Compatibility: All functionality remains available

For New Users:

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

File Organization

deb-mock/
├── debian/
│   ├── control                    # Multi-package control file
│   ├── deb-mock.install          # Core package files
│   ├── deb-mock-filesystem.install # Filesystem package files
│   ├── deb-mock-configs.install  # Configs package files
│   ├── deb-mock-plugins.install  # Plugins package files
│   └── deb-mock-dev.install      # Dev package files
├── deb_mock/                     # Core Python modules
├── filesystem/                   # Filesystem templates
├── configs/                      # Distribution configs
├── plugins/                      # Plugin modules
└── dev/                         # Development tools

Next Steps

1. Update debian/control for multi-package structure
2. Create package-specific directories and files
3. Implement package separation logic in build system
4. Test multi-package builds and dependencies
5. Update documentation for new package structure
6. Create migration guide for existing users

This approach provides a clean, modular packaging system that matches Fedora's successful multi-package strategy while being optimized for Debian's ecosystem.