Salut les Linuxiens de tout bords,
Je vais poser une question bête mais je préfère que des utilisateurs concernés par le sujet abordé répondent a ma question:
Quelles sont les distributions majeures sur lesquelles ont peut installer un paquetage *.deb.
Vous allez me répondre les distributions basé sur debian.
Mais je cherche plutôt des nom de distributions, ca sera plus rapide pour moi et pour vous, il vous suffit de bien vouloir me répondre si c'est le cas de votre distro favorite.
Pour info j'arrive maintenant a créer des paquetages *.deb pour distribuer mes programmes seulement il faut que je puisse tester le bon fonctionnement de l'installation et de l'exécution dans une VM (Virtual Machine).
Je vous serai grandement reconnaissant pour chaque réponse.
Merci d'illuminer de part vos réponses éclairées ma lanterne.
# un début de réponse (merci distrowatch !)
Posté par palm123 (site web personnel) . Évalué à 10.
http://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=Debian¬basedon=None&desktop=All&architecture=All&status=Active
ウィズコロナ
[^] # Re: un début de réponse (merci distrowatch !)
Posté par NeoX . Évalué à 4.
pas mieux
# Dérivées de Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Il est possible que des distributions non issues de Debian utilisent ce format de paquet, mais ça doit être un peu rare tout de même. Pour les dérivées donc :
https://wiki.debian.org/Derivatives/Census
https://wiki.debian.org/Derivatives
https://www.debian.org/misc/children-distros
[^] # Re: Dérivées de Debian
Posté par Adrien . Évalué à 1.
Petite question en passant : est-ce que toutes les dérivées de Debian récupèrent automatiquement les paquets de Debian ?
Parce que dans ce cas, il suffit de faire un paquet pour Debian, et hop ça sera disponible pour toutes les dérivées. Ce genre d'astuce peut intéresser du monde sur linuxfr.
[^] # Re: Dérivées de Debian
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Ça dépend, mais généralement oui. C'est notamment le cas d'Ubuntu : quand un paquet est envoyé dans Debia, il finit par arriver dans la version suivante d'Ubuntu.
# Format .deb et compatibilité
Posté par mazarini . Évalué à 2.
Bonjour,
Le fait d'utiliser le même format de package ne veux pas dire que les paquets peuvent être utilisés d'une distribution à l'autre. A contrario, on peut installer des rpm sur une Debian.
Plus qu'un format de paquets, une distribution est un ensemble cohérent de paquets. Ce n'est pas le paquet Debian que l'on retrouve sous Ubuntu, mais un paquet adapté aux spécificités d'Ubuntu. Il est possible que l'installation d'un paquet d'une autre distribution (ou d'une autre version d'une distribution) fonctionne sans problème, mais ce n'est jamais une certitude.
[^] # Re: Format .deb et compatibilité
Posté par Adrien . Évalué à 2.
Voir mon commentaire plus haut, mais il semble que dans un sens ça fonctionne.
Ubuntu par exemple récupère plus de 70% de paquet Debian sans modification. Donc si tu intègres ton paquet à Debian, il y a de forte chance qu'il atterisse dans Ubuntu, et que ça fonctionne. Pour un logiciel confidentiel, c'est une option très intéressant je pense.
Je suppose que pour les autres distributions c'est plus ou moins la même chose.
[^] # Re: Format .deb et compatibilité
Posté par freem . Évalué à 1.
En même temps, tu dis aussi que plus de 25%, soit plus d' 1 paquet sur quatre, est modifié…
Pour être un peu plus constructif et pas juste inverser des propos qui sont, au final, plutôt pertinents, je dirais que selon le langage, il sera très simple et sûr d'intégrer le paquet à une distro ou une autre sachant décompacter un .deb.
Pour généraliser, si on utilise un langage interprété, il y à de bonnes chances que la distro ne soit pas un problème: je doute qu'Ubuntu s'amuse à changer les noms des dépendances python pour rien, par exemple.
Par contre, dans le cas d'un truc compilé en langage machine (et pas en langage machine virtuelle, genre java), on s'expose à des problèmes d'ABI, et la, c'est vraiment pas sûr que ça passe de Debian à Ubuntu (ou l'inverse) sans perte ni fracas. J'ai déjà essayé d'installer un paquet buntu sur une Debian, même en trichant avec les noms des dépendances, ça se finissait en segfault à cause d'un problème de linkage.
[^] # Re: Format .deb et compatibilité
Posté par Adrien . Évalué à 2.
Il faut comprendre le processus: Ubuntu réutilise les paquets Debian en général, mais en personnalise certain, par ex. des paquets KDE. Mon propos était de dire que c'est possible d'avoir un seul paquet, intégré dans Debian et disponible dans pas mal de dérivé, sans travail supplémentaire.
Lorsque je crée un paquet pour Debian, je vais compiler mon paquet avec les dépendances disponible dans les dépôts Debian. Les versions sont différentes de celles d'Ubuntu, donc c'est normal que parfois ça ne fonctionne pas.
En revanche, le même paquet source peut très bien être récupéré et compiler automatiquement par Ubuntu, et du coup ça fonctionnera probablement sans rien changer.
[^] # Re: Format .deb et compatibilité
Posté par freem . Évalué à 1.
C'était juste pour jouer le chieur, hein, je suis d'accord avec ce que tu dis. Mon véritable propos est juste qu'il vaut mieux éviter de prendre pour acquis qu'une archive Debian tournera sur les dérivées sans problème.
Par contre, une fois recompilé, éventuellement avec quelques modif du DEBIAN/control, là oui, ça marchera tout le temps --à condition qu'il n'y ait pas nécessité de porter du code d'une version d'une lib à une autre bien entendu--.
J'imagine qu'il doit même du coup devenir possible d'utiliser un paquet source .deb pour générer une archive utilisable sur RHEL, fedora & co, ils doivent bien avoir un truc qui fasse l'inverse d'alien?
# merci pour vos réponses.
Posté par Linuxator (site web personnel) . Évalué à -5.
Merci pour vos nombreuse réponses je vais regarder les liens que vous m'avez laisser,
pour entrer dans la conversation,
d'abord:
Mon script Post-Install: le script qui est exécuter après la copie des fichiers d'un paquetage *.deb,
car c'est un peu comme créer un miroir qui sera installer sur la machine cible.
Par exemple si ont place des fichiers sous /usr/local/bin/ dans l'arborescence du paquetage *.deb, ceux-ci sont copier dans le dossier /usr/local/bin/ de la machine cible, puis le script Post-Install est exécuter (Il y a aussi Pre-Install, Pre-Remove, Post-Remove)
Mon script Post-Install Fait appel a des test comme:
Du coup si le paquet python-gtk2 n'est pas déjà installé il faut que la distribution cible utilise le système apt-get.
Sous Ubuntu aptitude n'est pas compris dans l'installation standard…
Ca fait un problème de compatibilité de plus, bien sur ont peut avoir la présence d'esprit de regarder les paquets dont le programme dépend quand ont installe le paquetage *.deb: c'est pas pour rien que cette information est compris dans le paquetage deb.
Et puis un paquetage *.deb valide n'est pas aisé a générer, car il existe un programme anmaired'heure qui s'appelle lintian et qui vérifie sévèrement la validité du paquetage *.deb.
Installerai vous le programme si pendant l'installation une fenêtre de dialogue s'ouvre et vous dit que le paquetage n'est pas valide ?
Avant je faisait des tarball avec des scriptes d'installation et de désinstallation compatible Ubuntu, mais il faut bien évoluer et le format *.deb en est une pour moi.
Si vous voulez évoluer je peut vous conseiller le programme DEBREATE dont je connait un tutoriel d'initiation.
Mais qui ne fait pas tout le travail quand il s'agit de créer un paquetage *.deb valide, je vous laisse vous dépatouiller si vous voulez générer des fichiers *.deb.
[^] # Re: merci pour vos réponses.
Posté par freem . Évalué à 1.
Euh… attend, pourquoi tu installes des paquets dans les scripts au juste? Si tu en dépends, ils doivent être listés dans le fichier DEBIAN/control, sur la ligne "Depends"!
Accessoirement, ça permettra aux gens qui suppriment apt-get de pouvoir utiliser ton paquet.
Ce n'est pas un programme emmerdeur, mais un programme qui t'aide à créer des paquets de qualité, chose importante pour les utilisateurs et les mainteneurs.
Mais tu n'es pas obligé d'être conforme pour diffuser ton paquet toi-même, c'est juste utile si et seulement si tu veux qu'il soit intégré dans Debian, et je ne suis même pas sûr que ce soit obligatoire…
Je n'ai jamais vu de telle fenêtre, pourtant j'ai utilisé des dépôts externes depuis quelques temps: codeblocks, opera, et i3. Le seul truc, c'est que j'ai parfois des avertissements comme quoi le contenu n'est pas signé (dans le cas de codeblocks avant, mais l'un des dev avait mis une clé pgp, et i3 ou il n'y à pas de signature ), mais ça ne m'a jamais empêché d'installer les paquets que je veux. C'est juste que je ne le ferai pas sur des machines sensibles en fait.
[^] # Re: merci pour vos réponses.
Posté par Linuxator (site web personnel) . Évalué à -5.
Je pensais a installer les dépendances pour mon programme (automatiser la tâche),
car si l'utilisateur cible clique ou exécute (dpkg -i) mon paquetage *.deb il peut soit:
-) avoir installer les dépendances tout seule dans ce cas pas de soucis mon script teste si les paquets sont installé avant l'appel a apt-get.
-) Exécuter bêtement le paquet afin d'installer le programme et dans ce cas le test et l'installation sont utile (sous condition d'une connexion internet et disponibilité de apt-get).
Et que faire si ce n'est pas le cas car le programme ne peut pas fonctionner sans ses paquets.
En faîte je pensais faire un peu comme apt-get et résoudre les dépendances automatiquement. Toujours est-il que mon paquetage n'est pas disponible sur le net pour l'instant, c'est pas pour rien que je poste dans un forum Linux avant.
Je doit créer un dossier cacher dans le $HOME de l'utilisateur pour les ressources de mon programme et ça a été un vrai calvaire de créer un paquetage valide car:
-) Utiliser des dossiers personnaliser dans un fichier *.deb qui ne soit pas:
-) /bin | /usr/bin | /usr/share/bin | et /usr/local/bin
N'est pas admis par lintian.
Heureusement que l'on peut exécuter un script…
Je trouve simplement que lintian est trop stricte et il est vrai que les paquetage se doivent d'être de qualité contrôler mais je répète lintian est trop restrictif car la fenêtre de dialogue avertis que le paquet peut compromettre le système ce qui n'est nullement le cas de mon paquetage et encore moins mon intention. (Ca m'est arriver avec le programme caine: après l'installation j'ai dû formater). Et cette restriction sévère de lintian est une entrave a la liberté des programmeurs Linux qui se dit (et il l'est) être un système libre, car il ne peuvent pas effectuer une tâche comme créer un dossier caché dans le $HOME de l'utilisateur sans passer par un dossier temporaire dans /usr/* …
[^] # Re: merci pour vos réponses.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Fait ça au postinst est une horreur, ce n'est pas du tout le rôle d'un script de post-installation. Il y a dans les infos du paquet un champ de dépendances, qui est là pour ça.
Car c'est une pratique horrible également de faire ça par le paquet : un paquet ne doit pas toucher aux répertoires personnels, mais seulement aux répertoires système. L'ajout de répertoires ou de fichiers dans le répertoire personnel de l'utilisateur, c'est au logiciel de le faire, au premier lancement.
Argh. Jamais un paquet comme ça ne serait admis dans Debian.
Lintian est strict pour faire respecter des conventions de qualité, que tu cherches à contourner. Il n'est pas étonnant que tu aies du mal. Tu es dans le cas typique du proverbe « les bons développeurs sont de mauvais empaqueteurs » : développeur, tu aimes coder, mais pas empaqueter, tout simplement.
[^] # Re: merci pour vos réponses.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Note que ce n'est pas une insulte, hein. C'est comme dire que je suis un mauvais musicien, c'est un fait et ça ne me dérange pas.
[^] # Re: merci pour vos réponses.
Posté par freem . Évalué à 2.
Mais ce n'est pas le rôle de dpkg.
Non…
Ça, c'est ton programme qui doit le faire, quitte à créer un 2nd programme dédié à ça, parce que si tu le fais lors de l'install, qu'adviendra-t-il si l'utilisateur, pour une raison X ou Y supprime "tes" fichiers? Qu'adviendra-t-il si un utilisateur est créé après l'installation?
Ce n'est pas parce que c'est libre que ça doit être le bordel. Lintian est là pour s'assurer que l'utilisateur est libre et le reste.
[^] # Re: merci pour vos réponses.
Posté par NeoX . Évalué à 3.
l'utilisateur lambda clique sur le .deb
ca ouvre le software center, ou synaptic qui calcule les dependances et les installe
s'il est un peu avancé, et qu'il veut faire ca en ligne de commande,
soit il utilise dpkg -i et il sait qu'il devra installer des dependances
soit il utilise gdebi qui va calculer les dependances et les installer pour lui.
tout le reste me fait peur et ne me donne clairement pas envie d'installer ton logiciel avec ton "installeur" qui veut creer des dossiers dans le repertoire de l'utilisateur ???
bloody hell… ce n'est pas (et n'a jamais été, meme sous windows) le role de l'installeur de faire cela.
c'est au logiciel de creer son dossier d'options/configurations/preferences de le faire au premier lancement si le dossier est absent, d'ailleurs il doit aussi respecter un formalisme,
je crois que maintenant c'est dans /home/user/.config/logiciel
[^] # Re: merci pour vos réponses.
Posté par Linuxator (site web personnel) . Évalué à -5.
Merci encore pour vos nombreuses réponses et réactions,
je pense que vous êtes tous plus efficace que lintian dans le but de créer mon premier programme distribuer sous forme de paquetage *.deb et ce n'est pas un sous entendus que ça soit clair c'est un compliment a la communauté Linux.
J'ai noter toutes vos réactions concernant le sujet et je pense changer quelques points de ma façon de faire avec mon programme et les paquetages *.deb.
Utiliser un répertoire système pour les ressources de mon programme car c'est possible sous Linux contrairement a Windows d'ou la pratique, du dossier dans le pseudo $HOME (en faîtes .AppData), vient:
pas possible de changer les droits (personnellement je n'y arrive pas) sous "Programmes Files"… et d'ailleurs je n'ai jamais essayer et essaierai jamais car j'ai débuté sous Linux et je finirai sous Linux. Mais comme ont dit l'on en apprends tous les jours.
Par contre, je suis d'avis que: la tache de créer un dossier dans le $HOME, si c'est vraiment nécessaire, ne doit en aucun cas revenir au programme, plutôt un sous programme créer pour l'occasion et qui s'efface tous seule après avoir accomplis sa tache car c'est possible, sauf si la performance n'est pas une priorité pas comme dans un jeu.
Bon après vos bons conseils et divergences qu'il faut jauger soit même, afin de vous proposer un programme installable sous forme de paquetage *.deb.
Je vous remercie encore pour votre coopération a mon premier paquetage deb.
C'est la que je balance le lien pour le programme seulement, j'ai quelques points a changer concernant celui-ci et vous n'y êtes pas étranger.
Question: êtes vous sur que la software center (Logithèque), ou gdebi, résout le problème d'installation des paquets dont dépend le programme automatiquement ?
PS: il est vrai que le script postinst est une horreur et sûrement une erreur de débutant, mais il est valide d'après mon amis lintian qui est de cet avis.
[^] # Re: merci pour vos réponses.
Posté par NeoX . Évalué à 2.
et il se passe quoi si un autre utilisateur lance le programme ?
il n'aura pas son dossier de preference ?
et si l'utilisateur veux remettre ses preferences à zero en supprimant le dossier de preferences ?
oui si tu as respecté le standart qui demande de lister (dans un certain formalisme) les dependances dans /DEBIAN/control
et concernant windows,
c'est le meme principe, le .AppData sous windows, c'est comme ton dossier preference,
ce n'est pas à l'installeur de le creer, mais à ton programme lors du premier lancement (ou des lancements suivants si le dossier a été éffacé)
les données internes du programme doivent etre dans le dossier du programme
[^] # Re: merci pour vos réponses.
Posté par Linuxator (site web personnel) . Évalué à -5.
Merci encore pour vos nombreuses réponses et réactions,
je pense que vous êtes tous plus efficace que lintian dans le but de créer mon premier programme distribuer sous forme de paquetage *.deb et ce n'est pas un sous entendus que ça soit clair c'est un compliment a la communauté Linux.
J'ai noter toutes vos réactions concernant le sujet et je pense changer quelques points de ma façon de faire avec mon programme et les paquetages *.deb.
Utiliser un répertoire système pour les ressources de mon programme car c'est possible sous Linux contrairement a Windows d'ou la pratique, du dossier cacher dans le pseudo $HOME (en faîtes .AppData), vient:
pas possible de changer les droits (personnellement je n'y arrive pas) sous "Programmes Files"… et d'ailleurs je n'ai jamais essayer et essaierai jamais car j'ai débuté sous Linux et je finirai sous Linux.
Mais comme ont dit l'on en apprends tous les jours.
Par contre, je suis d'avis que:
la tache de créer un dossier caché dans le $HOME, si c'est vraiment nécessaire, ne doit en aucun cas revenir au programme, plutôt un sous programme créer pour l'occasion et qui s'efface tous seule après avoir accomplis sa tache car c'est possible, sauf si la performance n'est pas une priorité - pas comme dans un jeu.
Bon après vos bons conseils et divergences qu'il faut jauger soit même, afin de vous proposer un programme installable sous forme de paquetage *.deb.
Je vous remercie encore pour votre coopération a mon premier paquetage deb.
C'est là que je balance le lien pour le programme seulement, j'ai quelques points a changer concernant celui-ci et vous n'y êtes pas étranger.
Question: êtes vous sur que la software center (Logithèque), ou gdebi, résout le problème d'installation des paquets dont dépend le programme automatiquement ?
PS: il est vrai que le script postinst est une horreur et sûrement une erreur de débutant, mais il est valide d'après mon amis lintian qui est de cet avis.
# de la lecture sur le packaging debian
Posté par NeoX . Évalué à 2.
https://wiki.debian.org/IntroDebianPackaging
en francais ici
https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.fr.pdf
# programmes distribuer sous forme de paquetage *.deb
Posté par Linuxator (site web personnel) . Évalué à -5.
Salut les Linuxiens de tout bords,
suite a vos précieux conseils et a vos réactions, j'ai publier 2 programmes distribuer sous forme de paquetage *.deb
Il est vrai que l'installation passe par un dossier temporaire dans /usr/local/bin qui est effacer une fois l'installation terminer car il n'est pas possible, du moins si l'on veut que sont paquetage soit valide, de copier les dossiers directement dans /usr/share/NomDeMonProgramme/.
Et j'ai aussi pris en compte vos réaction concernant la création du dossier car l'un des deux programmes a besoin d'un dossier de fichiers temporaires donc le programme crée a chaque démarrage après un petit test si le dossier si le dossier n'existe pas déjà suite a un lancement antérieur dans la même session, dans le dossier /tmp un dossier temporaire:
PyImaging: un programme de traitement d'images avec de multiples effets de des capacités de mixage d'images selon un algorithme:
il faut renseigner 2 fichiers en entré et parfois donner des paramètres et l'algorithme produit une image de sortie prévisualisable avant un éventuel enregistrement.
Sinon pour le simple traitement d'image les possibilités ne manquent pas.
Le programme supporte pas mal de formats de fichiers images.
Le fichier *.deb contient un *.pdf de documentation du programme.
EraserDropBox: Une drop box d'effacement sécurisé.
Il suffit de glisser-déposer le dossier ou fichier a effacer de manière sécurisé, car le programme fait appel au programme wipe comme sous-processus, dans la drop box suite a quoi
vous pourrez naviguer dans les dossiers sélectionnés ou ajouter, avec un sélecteur de fichier, retirer un fichier ou dossier ou encore retirer tous les éléments de la liste des fichiers et dossiers a effacer.
Bref un petit programme utile, simple et efficace.
Le processus d'effacement peut durer un petit moment wipe faisant bien sont boulot en fonction du nombre de fichiers dossier a effacer et du nombre d'itérations choisie (nombre d'écrasement des fichiers).
PS: Ce sont mes premiers programme utilisant comme GUI (py)GTK avant je faisais avec Tkinter.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.