Présentation du format cpak
cpak se définit comme le format OCI d’application destiné aux postes de travail, serveurs et appareils Linux. Le site indique que le système fonctionne immédiatement sur chaque distribution Linux, sans adaptation préalable. L’infrastructure repose sur deux binaires statiques qui constituent le runtime, ainsi qu’un magasin de contenu partagé utilisé par toutes les applications empaquetées.
Architecture technique et mécanismes
Le modèle s’appuie sur la spécification OCI d’image : chaque paquet possède un manifest clair et des couches (layers) décrites de façon identique à Docker. La syntaxe des Dockerfile est reconnue, ce qui permet le caching des couches et les constructions incrémentales sans recourir à un démon de conteneur en production. Cette approche conserve la traçabilité des dépendances tout en éliminant le besoin d’un moteur d’exécution supplémentaire.
Intégration GPU et accès aux ressources système
cpak propose une intégration GPU native : les pilotes graphiques du système hôte sont liés au lancement de l’application, évitant ainsi l’inclusion d’une pile de pilotes distincte dans chaque image. Le format autorise également la déclaration explicite d’accès à DBus, aux sockets et aux périphériques, limitant les privilèges aux seules ressources requises par l’application.
Versionnage Git‑native et modèle unique de paquet
Le système accepte tout tag, branche ou SHA de commit exact comme source d’installation, puis épingle le code qui doit recevoir les mises à jour. Cette capacité de versionnage Git‑native garantit la reproductibilité des builds. Par ailleurs, cpak utilise un modèle de paquet unique : le même manifest et la même commande sont déployés sur tous les environnements, chaque architecture disposant d’une image OCI dédiée.
Analyse des avantages et limites
Le recours à deux binaires statiques minimise l’encombrement du runtime tout en assurant une compatibilité large, mais il impose que chaque hôte fournisse les pilotes graphiques requis, ce qui peut restreindre la portabilité sur des systèmes aux drivers non standard. L’absence de démon de conteneur réduit la surcharge opérationnelle, mais diminue également l’isolation offerte par les conteneurs classiques, augmentant la dépendance à la robustesse du manifest. Le versionnage Git‑native améliore la traçabilité, toutefois il expose potentiellement le code source si les dépôts ne sont pas correctement protégés. Enfin, le modèle OCI garantit une interopérabilité avec les outils existants, mais la sécurité globale repose sur la précision des déclarations de ressources et sur la confiance accordée aux binaires statiques fournis par le projet cpak.
