Fonctionnement de l’emballage Podman sous Linux


  • Français


  • Au cours des derniers mois, le Podman project a retravaillé son processus de génération de packages Debian et Ubuntu. Cet article décrit le passé et le présent du travail d’empaquetage Debian effectué par l’équipe du projet Podman. Veuillez noter que cet article ne fait pas référence à la version officielle DebianName et Ubuntu packages que Reinhard Tartler et son équipe ont créés et maintenus.

    Processus de construction de Debian

    Pour faire court, le processus de construction typique de Debian implique la “débianisation” d’un référentiel en amont. D’abord, un debian Le sous-répertoire contenant les métadonnées d’empaquetage et tous les correctifs nécessaires est ajouté au référentiel en amont. Puis le dpkg-buildpackage la commande est exécutée pour générer le .deb paquets.

    Ancien processus de construction Debian pour Podman

    Auparavant, les packages Debian pour Podman étaient générés à l’aide de ce processus de “débianisation”. UN debian répertoire contenant les métadonnées d’emballage a été ajouté à la source Podman dans un fourche séparée. Ce fork a été rebasé pour chaque nouvelle version en amont de Podman.

    Problèmes avec le processus de construction Debian (pour un empaqueteur RPM)

    Alors qu’un simple rebasage fonctionnait souvent, ce n’était pas toujours le cas. Habituellement, la source Podman elle-même nécessiterait des correctifs pour que les choses fonctionnent pour plusieurs versions de Debian et Ubuntu, entraînant des échecs de rebase. Et les échecs dans un rebase signifiaient des échecs dans les tâches automatisées. Ce qui, à son tour, a causé beaucoup de frustration.

    Cette même frustration a conduit notre équipe à retirer les paquets Debian autrefois. Lorsque Podman v3.4 a officiellement fait son entrée dans Debian 11 et Ubuntu 22.04 LTS (grâce à l’incroyable Reinhard Tartler), nous avons pensé que le projet Podman pourrait dire adieu à la maintenance des paquets Debian.

    Mais ce n’était pas censé être. Debian et Ubuntu sont plutôt conservateurs dans leurs politiques de mise à jour des packages, en particulier dans leurs versions release et LTS. En conséquence, de nombreux utilisateurs de Podman sur les distributions basées sur Debian seraient bloqués avec la v3.4 pendant un certain temps, peut-être toute la durée de vie de la version de distribution. Bien que les utilisateurs puissent souvent installer les derniers packages à partir du référentiel expérimental de Debian, ce n’est pas nécessairement pratique pour tout le monde. En conséquence, de nombreux utilisateurs basés sur Debian a demandé le projet Podman pour les nouveaux forfaits.

    Si nous devions ressusciter les propres packages Debian du projet Podman, nous avions besoin que le format d’emballage soit facile à maintenir et à déboguer pour les empaqueteurs RPM et également facile à automatiser, ce qui signifiait qu’il n’y avait pas d’échecs fréquents avec les rebases et les correctifs.

    OBS + Debbuild

    La debbuild outil créé par Néal Gompa et d’autres, est un ensemble de macros d’empaquetage RPM permettant aux empaqueteurs de construire des paquets Debian en utilisant les sources d’empaquetage de Fedora. Idéalement, debbuild les packages peuvent facilement être ajoutés en tant que dépendances à un projet hébergé sur openSUSE Service de construction ouvert Infrastructure.

    Voici un extrait de la façon dont debbuild la prise en charge est activée pour Ubuntu 22.04 sur le Référentiel Kubic stable OBSmaintenu par le projet Podman :

     <repository name="xUbuntu_22.04">
        <path project="Ubuntu:debbuild" repository="Ubuntu_22.04"/>
        <path project="Ubuntu:22.04" repository="universe"/>
        <arch>x86_64</arch>
        <arch>s390x</arch>
        <arch>armv7l</arch>
        <arch>aarch64</arch>
      </repository>

    Le fichier de configuration complet est disponible ici.

    En plus d’activer debbuild packages en tant que dépendances, les sources de package Fedora doivent être mises à jour avec des règles pour modifier le processus de construction pour les environnements Debian et Ubuntu.

    Voici un extrait de la façon dont cela se passe pour Podman :

    %if "%{_vendor}" == "debbuild"
    Packager: Podman Debbuild Maintainers <https://github.com/orgs/containers/teams/podman-debbuild-maintainers>
    License: ASL-2.0+ and BSD and ISC and MIT and MPLv2.0
    Release: 0%{?dist}
    %else
    License: ASL 2.0 and BSD and ISC and MIT and MPLv2.0
    Release: %autorelease
    ExclusiveArch: %{golang_arches}
    %endif

    La ” %{_vendor}” == “debbuild” conditionnel est utilisé à de nombreux autres endroits dans le fichier de spécifications. Par exemple, dans cet exemple de code, il spécifie différents ensembles de dépendances et étapes de construction pour Fedora et Debian. Aussi, debbuild permet de conditionner les versions Debian et Ubuntu à l’aide des macros {debian} et {ubuntu}qui sont familiers aux empaqueteurs RPM.

    Vous pouvez trouver le fichier de spécifications RPM mis à jour avec tous les debbuild changements ici.

    Ensemble, ces deux éléments produisent des compilations de paquets Debian réussies sur le Référentiel Kubic instable OBS.

    Utilisant debbuild garantit également que les métadonnées d’empaquetage vivent dans son propre référentiel séparé, ce qui n’implique aucun problème de correctif ou de changement de base avec les sources Podman en amont.

    Convivialité

    À l’heure actuelle, des packages sont disponibles pour Ubuntu 22.04, Debian Testing et Debian Unstable. Nous sommes en pourparlers avec les responsables de l’infrastructure OBS pour ajuster les environnements de construction Debian 11 et Ubuntu 20.04, après quoi nous aurons également des versions réussies pour ces deux environnements.

    $ apt list podman
    Listing... Done
    podman/unknown,now 4:4.2.0-0ubuntu22.04+obs55.1 amd64 [installed]
    podman/unknown 4:4.2.0-0ubuntu22.04+obs55.1 arm64
    podman/unknown 4:4.2.0-0ubuntu22.04+obs54.1 armhf
    podman/unknown 4:4.2.0-0ubuntu22.04+obs54.1 s390x

    Parlons maintenant de l’utilisabilité. Ces packages ont été vérifiés manuellement et l’équipe Podman les a trouvés satisfaisants aux cas d’utilisation typiques. Les utilisateurs peuvent installer ces packages comme ils le feraient pour tout autre package DEB. Le référentiel doit d’abord être activé, et il y a des instructions sur le Site Web de Podman. Cependant, ces paquets ne sont pas approuvés par Debian. Ils n’ont pas suivi le même processus d’assurance qualité que les packages Debian officiels. Ces packages ne sont actuellement pas recommandés pour une utilisation en production, et nous vous invitons à faire preuve de prudence avant de procéder à l’installation.

    Emballer

    La debbuild permet à l’équipe du projet Podman de générer des packages Debian avec quelques ajouts aux sources d’emballage Fedora, ce qui facilite la maintenance, le débogage et l’automatisation des packages Debian. Il permet également aux utilisateurs de Debian et d’Ubuntu d’obtenir le dernier Podman à la même vitesse que les utilisateurs de Fedora. Les utilisateurs de Podman sur Debian et Ubuntu à la recherche des dernières mises à jour peuvent utiliser notre Kubic instable référentiel (idéalement pas encore sur les environnements de production.)

    Nous vous recommandons également vivement le debbuild et la configuration OBS aux conditionneurs RPM qui doivent fournir les packages Debian et Ubuntu à leurs utilisateurs. C’est une sélection variée d’outils, mais l’open source consiste à travailler ensemble.

    Source

    Houssen Moshinaly

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

    Copy code