Kristuff.
Créer un paquet debian (.deb) : guide pratique (ou pas ?! 🤔)
Par HelloWorld
dans Dev
package
Debian
Linux
Créer un paquet debian (.deb) : guide pratique (ou pas ?! 🤔)

debian-logo

.deb est le format de fichier des paquets logiciels de la distribution Debian GNU/Linux. Presque toutes les distributions basées sur Debian utilisent aussi ce format.

dpkg est un logiciel à la base du système de gestion de paquets de Debian. Des outils comme apt ou aptitude utilisent sous le capot dpkg.

Cet article présente l'architecture des paquets .deb et les principales étapes, les outils et les fichiers nécessaires à leur création.

Sommaire

Paquet binaire VS paquet source

Il existe deux types de paquets : un paquet source et un paquet binaire :

  • Le paquet binaire (.deb) est le paquet prêt à l'emploi regroupant des binaires précompilés et des scripts d'installation prêts à être fournis directement à un utilisateur final. C'est le type de paquet que l'on installe habituellement avec la commande apt-get. Sa structure est normalisée est décrite dans la Charte Debian.

  • Le paquet source est celui qui peut être utilisé pour construire la version binaire à la demande. Le paquet source est un peu plus difficile à assembler et est soumis à un certain nombre de règles techniques et juridiques avant d'être acceptable pour les principales distributions Linux.

La suite de cet article concerne la création de paquets binaires.

Pourquoi créer un paquet ?

Selon la nature du logiciel, sa complexité, le language utilisé, son installation sur un système et sa mise à jour peuvent être des tâches fastidieuses.

Dans certains cas, utiliser un simple script shell est suffisant. Dans d'autres cas, il peut être intéressant ou nécessaire de créer un paquet :

  • le processus et les paramètres d'installation doivent être adaptés pour le système d'exploitation ciblé ;
  • le logiciel intéragit avec des services de la machine ;
  • le logiciel dépend de logiciels tiers.

Créer ses propres paquets peut être un moyen d'empaqueter ses propres outils, ou de déployer des logiciels sur une flotte de clients.

Un paquet binaire peut être utilisé :

  • manuellement avec dpkg (dpkg -i <package> pour l'installer et dpkg -r <package> pour le supprimer).

  • ou peut être intégré dans un dépôt privé géré par apt. Dans ce cas, les dépendences seront installées automatiquement si besoin, et le déploiement des mises à jour est facilité.

Contenu d'un paquet binaire

Les paquets Debian sont des archives ar qui contiennent votre application et d'autres fichiers utilitaires. L'archive contient trois fichiers :

control.tar.gz
data.tar.gz
debian-binary

Les deux premiers fichiers sont des archives tar compressées :

  • control.tar.gz : contient les utilitares pour l'installation. Le principal est le fichier control qui contient des informations sur le paquet comme son nom, sa version, les dépendances, etc.

  • data.tar.gz : le fichier contient une collection de dossiers qui imite un système de fichiers Linux typique depuis la racine, tel que /usr, /usr/bin, /opt, /etc, ...). Un fichier placé dans l'un de ces répertoires sera copié au même emplacement dans le système de fichiers réel lors de l'installation.

    Par exemple, si le paquet doit installer foo dans /usr/bin et bar dans /etc/foo, le fichier contiendra deux dossiers usr et etc, qui contiendront eux-mêmes les dossiers bin et foo, et qui contiendront eux-mêmes fichiers foo et bar.

Le troisième fichier est debian-binary. Il contient la version du format Debian (actuellement 2.0).

Convention de nommage des fichiers deb

Tous les fichiers .deb suivent une convention de nommage spécifique :

{nom}_{version}_{architecture}.deb
  • nom : le nom de votre application ;
  • version : le numéro de version de votre application ;
  • architecture – l'architecture matérielle sur laquelle votre programme sera exécuté (par exemple amd64).

Par exemple, imaginons le programme appelé helloworld, version 1.0, conçu pour les processeurs ARM 64 bits. Le nom du fichier .deb ressemblerait à helloworld_1.0_arm64.deb.

Construire le paquet : les outils

Le programme utilisé pour générer l'archive finale est dpkg-deb.

Le paquet lintian est fortement conseillé pour vérifier le paquet créé (voir l'article vérifier un paquet Debian avec Lintian).

La création d'un paquet avec dpkg-deb est realisée avec la commande -b | --build :

dpkg-deb [<options>] --build <répertoire source> [<archive>|<répertoire de destination>]

Cette commande crée une archive Debian avec l'arborescence contenue dans le dossier répertoire source, soit dans l'archive soit dans le répertoire de destination spécifié dans le second paramètre.

Construire le paquet : le répertoire source et les fichiers obligatoires

Le répertoire source doit posséder un sous-répertoire DEBIAN qui contient les fichiers de contrôle tels que le fichier control lui-même.

Ce répertoire n'apparaît pas dans l'archive de l'arborescence du paquet binaire, mais les fichiers qu'il contient sont mis dans la zone de contrôle du paquet (le control.tar.gz vu plus haut, le reste étant dans l'archive data.tar.gz).

<répertoire source>
    ├─ DEBIAN                   # obligatoire
    │   ├─ control              # obligatoire
    │   ├─ conffiles            # option, voir fichiers de configuration
    │   ├─ preinst              # option, voir scripts du responsable
    │   ├─ postinst             # option, voir scripts du responsable
    │   ├─ prerm                # option, voir scripts du responsable
    │   └─ postrm               # option, voir scripts du responsable
    └─ usr
        └─ share
            └─ doc              
                └─ <pkg>       # dossier de documentation du paquet <pkg>
                    ├─ copyright            # obligatoire
                    └─ changelog.Debian.gz  # obligatoire

Les fichiers spécifiques au paquet sont présentés dans les sections suivantes :

Les deux derniers fichiers sont placés dans le dossier de documentation du paquet. Ce dossier va s'appeler /usr/share/doc/project1 si le nom du paquet est "project1". Il sont marqués obligatoire. En fait, ils sont obligatoires dans un paquet source et se retrouvent dans le binaire. Vous pouvez perdre des fonctionalités s'ils sont absents (comme apt changelog), mais techniquement, seul le fichier de control est nécessaire.

Le reste du répertoire contient les fichiers du programme à déployer sur les clients. Les emplacements sont plus ou moins libres, il doivent respecter certaines conventions.

Lorsqu'on déploit un exécutable, il est généralement placé dans /usr/bin. Les fichiers de ressources du programme sont généralement déployés dans usr/share/<pkg>, et une bibliothèque dans usr/lib/<pkg> (ou <pkg> et le nom du paquet).

Pour créer les répertoires, l'option -p de la commande mkdir s'ocuppera de créer des répertoires imbriqués. Supposons que le répertoire source situé dans le répertoire courant s'appelle build :

# populate source 
mkdir -p build/DEBIAN                   # dossier système
mkdir -p build/usr/bin                  # dossier pour les exécutables
mkdir -p build/usr/share/doc/project1   # dossier de documentation 
mkdir -p build/usr/share/project1       # dossier de ressources
...

Ne pas déployer dans /usr/local ou /opt

Si votre application a été installée dans /usr/local, dpkg affichera le message de suivant pendant la désinstallation :

le répertoire /usr/local n'était pas vide, il n'a donc pas été supprimé.

Pourquoi vouloir supprimer /usr/local ? Parce qu'il ne s'agit pas d'un emplacement géré par dpkg. Ce répertoire est présent sur la plupart des distributions mais dpkg le traite comme n'importe quel répertoire que vous auriez créé.

Utiliser /usr/local n'est pas autorisé, tout comme /opt ne l'est pas non plus. Ces répertoires sont réservés aux logiciels tiers installés autrement que par dpkg.

Cela reste techniquement possible, vous pourrez construire le paquet et l'installer avec dpkg -i, mais il ne serait pas accepté dans un dépot Debian.

Construire le paquet : le fichier DEBIAN/control

Dans le répertoire DEBIAN, c'est le seul le fichier obligatoire. C'est un simple fichier texte.

Le fichier de contrôle n'est qu'une liste de champs de données. Pour les packages binaires, il existe un ensemble de champs obligatoires :

  • Package : le nom de votre programme, en minuscules. Du fait de la regex {name}_{version}_{arch}.deb, le nom ne doit pas contenir d'underscore _.

    En fait, les noms de package (à la fois source et binaire) ne doivent être constitués que de lettres minuscules (a-z), de chiffres (0-9), de signes plus (+) et moins (-) et de points (.). Ils doivent comporter au moins deux caractères et doivent commencer par un caractère alphanumérique.

  • Version : la version de votre programme. Ce champs doit respecter certaines conventions. Généralement, il s'agit à minima de la version principale et numéro de révision (par exemple 1.0) ;

  • Architecture : l'architecture cible. Si votre paquet cible une ou plusieurs architectures particulières, elles doivent être listées (séparées par un espace si besoin). Sinon utilisez le mot clé all pour cibler toutes les architectures ;

  • Mainteneur : le nom et l'adresse e-mail de la personne en charge de la maintenance du paquet sous la forme :

    author <email@example.com>

  • Description – une brève description du programme. Pour éviter un warning avec lintian, la description doit être suivie d'une description étendue sur la ligne suivante (une ligne minimum qui doit commencer par un espace, un point si besoin pour ajouter une ligne vide). Chaque ligne ne doit pas comporter plus de 80 caractères.

    Description: A program that greets you.
 You can add a longer description here. Mind the space at the 
 beginning of this paragraph.
 .
 The dot is needed to add a new line

Les champs suivants sont recommandés (dpkg va fonctionner mais peut émettre des alertes si ces champs sont manquants) :

  • Section : Les paquets Debian dans les dépôts main, contrib et non-free sont regroupés en sections pour simplifier leur manipulation. La liste des sections est la suivante :

    admin, cli-mono, comm, database, debug, devel, doc, editors, education, electronics, embedded, fonts, games, gnome, gnu-r, gnustep, graphics, hamradio, haskell, httpd, interpreters, introspection, java, javascript, kde, kernel, libdevel, libs, lisp, localization, mail, math, metapackages, misc, net, news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, rust, science, shells, sound, tasks, tex, text, utils, vcs, video, web, x11, xfce, zope

    utils est assez générique et convient dans de nombreux cas.

  • Priority : La priorité des paquets définit quels paquets sont inclus dans les installations Debian standard ou minimales. La plupart des paquets Debian auront une priorité optional.

D'autres champs optionnels existent, la liste complète est disponible dans le manuel Debian.

Parmi eux, on notera ceux permettant de définir les dépendances :

  • Depends, Pre-Depends, Recommends, Suggests, Enhances, Breaks et Conflicts. La gestion des dépendances dans les paquets fera l'objet d'un article à par entière et ne sera pas abordée ici.

Voici un exemple complet de fichier control :

Package: myawesomeapp
Version: 1.0.8
Maintainer: john <john@example.com>
Architecture: all
Description: MyAwesomeApp is awesome. It does a lot of things and more.
 MyAwesomeApp is really awesome. It does a lot of things and more.
 .
 MyAwesomeApp is really really awesome. It does a lot of things 
 and more.
Priority: optional
Section: utils

Notez le retour à la ligne sur la dernière ligne, chaque ligne de données doit obligatoirement se terminer par un retour à la ligne

Construire le paquet : les scripts du responsable

Dans certains cas, l'installation d'un logiciel se limite à la copie de fichiers (exécutables, bibliothèque) sur l'ordinateur cible et le programme ou la commande peut fonctionner.

Dans d'autre cas, le procéssus d'installation ou de désinstallation demande des actions complémentaires, comme par exemple le démarrage/l'arret d'un service, la création de fichiers non inclus dans le paquet, définir des permissions, ...

Pour cela, quatre fichiers postinst, preinst, postrm et prerm, appelés scripts du responsable peuvent être utilisés selon les besoins. De tels fichiers résident dans le répertoire DEBIAN et, comme leurs noms l'indiquent, preinst et postinst sont exécutés avant et après l'installation, tandis que prerm et postrm sont exécutés avant et après la suppression.

Ils doivent être marqués comme exécutables, et les pemissions sur les fichiers doivent être comprises entre 0755 et 0775. Et pour passer les tests avec lintian, set -e est obligatoire.

Quelque exemples d'utilisation :

  • Un programme est constitué d'un exécutable, lui même chargant d'autres fichiers sources dans le même répertoire, grâce à leur emplacement relatif. Si l'on souhaite déployer l'exécutable dans /usr/bin, il faudrait y copier aussi tous les fichiers sources, ce qui n'est pas acceptable.

    A la place, on peut conserver l'ensemble du projet dans un répertoire, et utiliser le script postinst pour créer, après l'installation, un lien symbolique dans /usr/bin pointant vers le programme. Le script prerm sera utilisé pour supprimer le lien symbolique avant la suppression du paquet.

  • un programme installe un service et doit le démarrer après l'installation (postinst). Avant la suppression du paquet, on devrait alors arrêter le service s'il est actif (prerm).

  • un programme peut provoquer des erreurs sur certains systèmes : le script preinst pourrait effectuer des vérifications supplémentaires (que celles pouvant être définis par des contraintes comme Depends, Conflicts, ...) pour empêcher l'installation sur de tels systèmes.

  • le script postrm peut être utilisé pour nettoyer le système (suppressions, par exemple, de fichiers temporaires créés par le programme), seulement une fois que le paquet a été complètement désinstallé.

Construire le paquet : les fichiers de configuration

Tous les fichiers placés dans /etc/ doivent être marqués comme conffiles : dpkg va ensuite détecter les changements effectués et alerter avant de remplacer un fichier modifié.

Par exemple, supposons que le répertoire source contient le fichier /etc/project1/main.conf. Ce fichier de configuration sera declaré dans le fichier DEBIAN/conffiles comme suit (notez le retour à la ligne) :

/etc/project1/main.conf

La gestion des fichiers de configuration est un point délicat : c'est barbant de perdre sa configuration lors d'une mise à jour, et les messages interactifs lorsqu'une nouvelle version d'un fichier est disponible devraient être évités au maximum.

Pour éviter de déclarer les fichiers de configuration (et ainsi les messages interactifs), le manuel propose de créer et gérer les fichiers de configuration dans les scripts du responsable.

En tant que développeur, une solution alternative que je privilégie est d'installer un fichier de configuration dans /etc et de laisser la possibilité à l'utilisateur de modifier la configuration dans un fichier .local ou local.conf, de la même façon qu'un programme comme fail2ban gère ses fichiers de configuration. Cela permet, dans la plupart des cas, de mettre à jour les fichiers de configuration du paquet sans interaction et sans toucher aux personnalisations de l'utilisateur.

Chaque paquet source doit être accompagné d'une copie textuelle de sa ou ses licence(s) de distribution (Machine-readable debian/copyright file) dans le fichier /usr/share/doc/<pkg>/copyright.

Si vous constuisez votre propre paquet, il n'est pas obligatoire d'utiliser le format lisible par la machine, mais cela vous préparera à publier le paquet dans les distributions Debian.

Le fichier copyright ne doit ni être compressé ni être un lien symbolique. Il doit indiquer (le cas échéant) où les sources ont été obtenues, et doit inclure un nom ou une adresse de contact pour les auteurs.

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: mypackage
Upstream-Contact: Jonn Do <johndo@example.com>
Source: https://github.com/myorg/myproject

Files: *
Copyright: 2020-2021 Jonn Do <johndo@example.com>
License: MIT License 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 [...]

Files: subproject/*
Copyright: 2019 Jonn Do <johndo@example.com>
License: GPL-3+

Les packages distribués certaines licences, dont Apache2.0, GNU GPL (versions 1, 2 ou 3), la GNU LGPL (versions 2, 2.1 ou 3), [ ... ], doivent faire référence aux fichiers correspondants sous /usr/share/common-licenses, plutôt que de les citer dans le fichier de copyright.

Le fichier copyright ne doit pas être utilisé comme fichier README général et doit être encodés en UTF-8.

Construire le paquet : le fichier changelog

Le fichier changelog est un un fichier obligatoire du paquet source, avec un format spécifique décrit dans la Charte Debian, encodé en UTF-8.

Ce format est utilisé par dpkg et d'autres programmes pour obtenir le numéro de version, de révision, de distribution et l'urgence de votre paquet. Il est conservé dans /usr/share/doc/<pkg>/changelog.Debian.gz dans le paquet binaire.

Sa syntaxe est la suivante :

package (version) distribution(s); urgency=urgency
  * change details
  more change details
  * even more change details
 -- maintainer name <email address>[two spaces]  date

  • La première ligne contient le nom du paquet, la version, la distribution et l'urgence. Le nom doit correspondre au nom du paquet source, la distribution devrait être unstable, et l'urgence devrait être en medium à moins qu’il n’existe une raison particulière pour une autre valeur.

  • La dernière ligne (qui commence par 1 espace) comporte le nom du responsable, son adresse email (entourée de < et >), suivi (après 2 espaces) de la date. La date a le format suivant (compatible et avec la même sémantique que les RFC 2822 et RFC 5322) :

    day-of-week, dd month yyyy hh:mm:ss +zzzz

    Par exemple : Thu, 09 Dec 2021 19:00:00 +0100

  • Entre les deux, chaque ligne commence par 2 espaces, le signe * pour chaque entrée.

Voici un exemple complet :

project1 (1.0-1) unstable; urgency=medium

  * fix...

 -- John Do <johndo@example.com>  Thu, 09 Dec 2021 19:00:00 +0100

project1 (1.0-0) unstable; urgency=medium

  * initial release

 -- John Do <johndo@example.com>  Sun, 28 Nov 2021 19:00:00 +0100

Tous ces fichiers doivent être installés compressés à l'aide de gzip -9, car ils deviendront volumineux avec le temps, même s'ils sont petits au départ.

Problème connu :

Le fichier changelog.Debian.gz provient en théorie d'un paquet source. Si on l'ajoute seul, on obtient l'alerte suivante avec lintian : wrong-name-for-changelog-of-native-package.

Si on ajoute à la place changelog.gz, on obtient cette fois une erreur : debian-changelog-file-missing-or-wrong-name. Et on perd également la possibilité d'appeler apt-get changelog <pkg>.

Une autre solution consiste à créer deux fichiers changelog.Debian.gz et changelog.gz mais ce qui aura pour conséquence une autre alerte duplicate-changelog-files.

Construire le paquet : les permissions

  • Propriétaire(s) des fichiers/dossiers

    Dans un paquet, les fichiers appartiennent généralement à l'utilisateur root. Mais les fichiers sources à inclure dans le paquet peuvent avoir un/des propriétaire(s) différent(s).

    Lorsque le paquet est construit par l'utilisateur root, la commande chown peut être utilisée :

    chown -R root:root  <répertoire source>

    Dans les versions récentes de dpkg (>=1.19.0), on peut lancer la commande dpkg-deb en tant que simple utilisateur, et définir le propriétaire à root avec l'option --root-owner-group :

    dpkg-deb --root-owner-group --build <répertoire source> [<archive>|<répertoire de destination>]

    --root-owner-group

    Fixe le propriétaire et le groupe de chaque entrée dans les données de l'arborescence du système de fichiers à root avec l'identité 0 (depuis dpkg 1.19.0).

    Cette option sera utile dans la plupart des cas, sauf si une partie du contenu appartient à un autre utilisateur (www-data par exemple).

  • Permissions sur les fichiers/dossiers

    Sauf dans certains cas, essentiellement pour des raisons de sécurité, les répertoires sont généralement en lecture/écriture pour le propriétaire, et en lecture pour les autres.

    Seuls les fichiers exécutables doivent posséder l'attribut d'exécution. Les autres fichiers, comme pour les répertoires, sont modifiables uniquement par le propriétaire sinon en lecture seule.

    Supposons que le répertoire build est le point d'entré du répertoire source :

    # adjust ownerships
find build -type d -exec chmod 0755 {} \;          #set directory attributes
find build -type f -exec chmod 0644 {} \;          #set data file attributes
find build/usr/bin -type f -exec chmod 0755 {} \;  #set executable attributes only when required

Construire le paquet : le répertoire de destination

Dans la commande pour la création du paquet :

dpkg-deb [<options>] --build <répertoire source> [<archive>|<répertoire de destination>]

Quand le second argument est un répertoire (répertoire de destination), dpkg-deb définit lui même le nom du paquet (selon la convention {paquet}_{version}_{arch}.deb) en fonction des informations trouvées dans le fichier DEBIAN/control.

Dans ce cas, l'option --nocheck ne doit pas être utlisée :

À moins de préciser --nocheck, dpkg-deb lit le fichier DEBIAN/control et l'analyse. Il cherche les erreurs de syntaxe et d'autres problèmes existants, puis il affiche le nom du paquet binaire qu'il construit. dpkg-deb vérifie aussi les permissions des scripts du responsable et des autres fichiers qu'il trouve dans le répertoire de contrôle DEBIAN.

Quand un répertoire cible est précisé à la place d'un fichier, l'option --nocheck ne doit pas être utilisée (puisque dpkg-deb a besoin de lire et d'analyser le fichier de contrôle du paquet pour connaître le nom de fichier à utiliser).

Cas pratique : empaquetage du projet helloworld

Le projet helloworld est un ensemble de scripts shell (.sh). bin/helloworld.sh est le fichier exécutable principal, il a besoin de sourcer 2 autres fichiers situés dans le répertoire scripts.

~/helloworld
    ├─ .git
    |    └─ ...                   
    ├─ bin
    |    └─ helloworld.sh
    ├─ scripts
    |    ├─ util1.sh              
    |    └─ util2.sh              
    └─ TODO.txt

Le dossier contient des dossiers et fichiers que nous ne voulons pas dans l'archive (.git n'a rien à y faire, le fichier TODO.txt contient des notes internes du développeur).

Nous voulons automatiser la création du paquet dans un script et allons créer des dossiers et fichiers spécifiques :

cd ~/helloworld
mkdir deb-utils
mkdir deb-build
mkdir deb-dist
touch create_package.sh
  • deb-utils : contiendra les fichirs spécifiques au paquet (fichier de contrôle, scripts)
  • deb-build : ce dossier temporaire correspondra au répertoire source
  • deb-dist : le répertoire de destination où seront stockés les paquets générés.
  • create_package.sh : le script pour la création du paquet.

Comme l'exécutable helloworld.sh doit sourcer d'autres fichiers (util1.sh et util2.sh), on ne peut pas tous les placer dans /usr/bin. On va plutôt placer l'ensemble du projet dans /usr/lib et utiliser les scripts postinst et postrm pour créer un lien symbolique après l'installation et le supprimer après la désinstallation.

  • Création du fichier control

    touch deb-utils/control

    Editez le fichier avec votre éditeur favoris :

    Package: helloworld
Version: 1.0-1
Maintainer: John Do <johndo@example.com>
Architecture: all
Description: helloworld is a shell command that prints hello world
 helloworld package is really awesome. helloworld package is 
 really really awesome. 
Priority: optional
Section: utils

  • Création des scripts postinst et postrm :

    touch deb-utils/postinst
touch deb-utils/postrm

    Editez le fichier postinst dans lequel nous allons créer un lien symbolique pour le fichier exécutable (notez que les exécutables avec shebang placés dans /sur/bin ne devraient pas contenir d'extension, helloworld.sh sera appelé helloworld) :

    #!/bin/sh
set -e
ln -s /usr/lib/helloworld/bin/helloworld.sh /usr/bin/helloworld

    Et on le supprime dans le fichier postrm :

    #!/bin/sh
set -e
\rm /usr/bin/helloworld

    La commande rm est échappée avec \ pour prévenir d'un éventuel alias.

  • Création du script create_package.sh

    #!/bin/sh

# On s'assure que le dossier temporaire est *clean* 
rm -rf deb-build
mkdir deb-build

# Création de la structure du paquet
mkdir -p deb-build/DEBIAN
mkdir -p deb-build/usr/lib/helloworld

# Copie des fichiers dans le répertoire source. 
# D'abord le répertoire DEBIAN puis le contenu de l'application
cp deb-utils/control     deb-build/DEBIAN
cp deb-utils/postinst    deb-build/DEBIAN
cp deb-utils/postrm      deb-build/DEBIAN
cp -R scripts            deb-build/usr/lib/helloworld
cp -R bin                deb-build/usr/lib/helloworld

# définit les attributs 
find deb-build -type d -exec chmod 0755 {} \;  # Dossiers
find deb-build -type f -exec chmod 0644 {} \;  # Fichiers 
find deb-build/usr/lib/helloworld/bin -type f -exec chmod 0755 {} \;  # exécutables

# scripts du paquet
chmod 755 deb-build/DEBIAN/postinst
chmod 755 deb-build/DEBIAN/prerm

# et finalement on construit le paquet avec --root-owner-group pour 
# définir root en tant que propriétaire de l'ensemble du contenu du paquet
dpkg-deb --root-owner-group --build deb-build deb-dist

Il ne reste qu'à exécuter le script :

# se placer dans le dossier helloworld avant de lancer le script
chmod +x create_package.sh
./create_package.sh

Le script va générer le fichier helloworld_1.0-1_all.deb dans le dossier deb-dist.

Vous pouvez l'installer avec dpkg (en root) :

dpkg -i deb-dist/helloworld_1.0-1_all.deb
Sources et références
Partager cet article ...OU NE PAS.?
Commentaires 0
    Laisser un commentaire
    Les nouveaux commentaires ne sont pas acceptés.
    Bonjour, H o l a, H e l l o, a l l, t h e W o r l d ( a n d L i f e :)