Forums des Zéros

9 juillet 2010 à 21:56:30

JE TIENS À REMERCIER DELPHIKI POUR AVOIR PRIS MIS CE TOPIC EN POST-IT

Topic Unique de la Slackware Linux

Présentation

Slackware Linux est l'une des plus anciennes distributions Linux encore développée aujourd'hui.

Citation : Wikipédia

C'est également la plus vieille distribution encore en activité, ayant été pendant bien longtemps l'œuvre de Patrick J. Volkerding. Au fil des années, il accepta l'aide de quelques contributeurs - très peu - afin de l'aider dans le développement de Slackware (aussi à cause de sa maladie qui l'empêcha de contribuer pleinement à Slackware durant l'année 2005). Tout le monde attendait la mort de cette distribution maintenue par un seul homme et pourtant, plus d'une dizaine d'années après, elle est consciencieusement tenue à jour, toujours populaire et est utilisée comme base pour de nombreuses distributions dérivées.

Philosophie

Certes, Slackware Linux est très bien faite, mais elle ne convient pas à tout le monde, ni à toutes les utilisations. On a souvent dit, à tort, que la Slackware n'avait pas de gestionnaire de paquet. C'est seulement vrai au sens moderne du terme. En effet, il y a un gestionnaire de paquet sous Slackware : installpkg, removepkg, upgradepkg et makepkg. Chacun de ces programmes exécute une tâche précise : installpkg... installe un logiciel; removepkg... déinstalle; upgradepkg... met à jour; makepkg crée un paquet compilé sous forme logiciel.tgz. Il ne fallait pas être trop perspicace pour deviner tout ça

Encore une fois, je vous mets un petit passage de Wikipédia :

Note : les [...] ont été ajoutés par moi

Citation : Wikipédia

La Slackware se veut être une distribution légère, rapide et sans fioritures. Elle se démarque par une procédure d'installation en mode semi-graphique [dialog], un système de paquetages logiciels composé simplement d'archives tarballs [.tgz] sans gestion des dépendances, ainsi que par un processus de démarrage reposant sur un ensemble de scripts aisément modifiables « à la main » (elle ne dispose d'ailleurs pas d'un logiciel de configuration centralisé). De par ces caractéristiques, elle est fort appréciée sur les serveurs.

Liste des distributions dérivés de la Slackware

Note : Cette section est cachée, car elle n'est importante que pour ceux qui la considèrent comme telle.

Dérivées de Slackware pour Intel (x86)

* Blin - Distribution ukrainienne.
* Burapha Gnu/Linux - Distribution thaïlandaise développée par une équipe de l'université de Burapha.
* CEMF - Distribution brésilienne qui opère directement de dedans une partition ou installation Windows.
* College - Distribution suisse qui prétend se fonder sur Debian, mais dont le management des paquets est en .tgz ; la distribution est devenue un LiveCD.
* Cytrun - Distribution brésilienne développée afin d'augmenter les niveaux de sécurité des serveurs.
* Darkstar - Distribution roumaine.
* HostGIS - Distribution étasunienne, spécialement développée pour opérer des serveurs web cartographiques GIS.
* iWhaX - Distribution étasunienne orientée vers la sécurité et les réseaux ; c'est l'ancienne WhaX.
* JoLinux - Distribution brésilienne compilée avec le noyau Linux de la branche 2.6 par défaut.
* KateOS - Distribution polonaise développée par Damian Rakowski.
* Kinux - Distribution brésilienne.
* NetSecL - Distribution axée sur la sécurité.
* NimbleX - Distribution roumaine développée par Bogdan Radulescu.
* OpenLAB - Distribution sud-africaine, destinée à l'enseignement dans les écoles et les facultés ; en dehors de l'Afrique du Sud, elle est adoptée en Namibie et en Allemagne ; c'est la distribution pour laquelle les logiciels EduKar, OpenBook et ZybaCafe ont été développés ; il y a aussi un LiveCD qui peut être téléchargé librement, mais l'ensemble de 4 CDs / 1 DVD et les logiciels externes sont chargés.
* Polux (anciennement P!tux) - Distribution française pouvant être installée sur des vieux ordinateurs (dits ordinosaures), c'est l'ancien Drinou Linux.
* PC Master - Distribution brésilienne.
* Plamo - Distribution japonaise en langue japonaise pour faciliter le « slackage » des utilisateurs japonais.
* pQui - Distribution brésilienne pour les ordinateurs de bureau.
* Revanche - Distribution brésilienne dérivée simultanément de Slackware et de Fedora.
* RFS - Distribution brésilienne.
* RIP (Recovery Is Possible) - Distribution étasunienne implémentée pour la récupération de données.
* Root - Distribution suédoise développée par John Eriksson.
* RUNT (ResNet USB Network Tester) - Distribution Linux étasunienne développée par une équipe de l'université de Caroline du Nord pour être installée dans des clés USB ainsi que sur des disquettes qui interagiront ensemble ; la distribution est orientée vers les tests de réseaux et de portails USB.
* SauverOS - Distribution indienne développée par Maulik Gordhandas.
* Tukaani - Distribution finlandaise dont le point fort est la gestion de paquets à travers son installeur pkgtools et de son compacteur et démarreur LZMA : ils compatibilisent des paquets aux formats .tgz, .tbz, .tlz et .tar.
* VectorLinux - Distribution canadienne développée par Robert S. Lange ; elle se présente comme une excellente alternative pour donner de nouveaux usages à de vieux PC.
* Volta - Distribution italienne 100 % compatibilisée de double gestion de paquets : pkgtool de Slackware pour le système et pkgsrc de NetBSD pour les applications ; en d'autres termes, avec Volta Linux, on a pratiquement une Slackware et un NetBSD fonctionnant dans un même système d'exploitation.
* ZenServer - Distribution française pour les serveurs, basée sur Zenwalk.
* Zenwalk - Distribution française développée par Jean-Philippe Guillemin, elle contient des améliorations telles qu'un noyau 2.6 et le support de Reiser4. Cette distribution est optimisée pour le multimédia, le développement et la bureautique ; c'est l'ancienne MiniSlack.

Slackware pour AMD64

* Slackware64 - Distribution officielle, depuis la version 13.0 (en date du 27 août 2009) un portage officiel sur l'architectures X86_64 est disponible.
* Slamd64 - Distribution britannique, portage sur l'architecture AMD 64 bits (AMD64 ; x86 64).
* Bluewhite64 - Distribution roumaine, portage sur l'architecture AMD 64 bits (AMD64 ; x86 64) ; disposée en forme de LiveCD installable et de DVD d'installation.

Slackware pour ARM

* ARMedslack - Distribution étasunienne portée sur l'architecture ARM.

Slackware pour IBM S/390

* Slack/390 - Distribution étasunienne, portage sur l'architecture IBM S/390.

Slackware pour PowerPC (Macintosh)

* SlackIntosh - Distribution suisse, portage sur l'architecture PPC (PowerPC).

Slackware pour SPARC
* Splack - Distribution étasunienne, portage sur l'architecture SPARC.

CD autonomes

* 4Bak - canadien pour la récupération de contenu développé par Sylvie Migneault ; c'est l'ancien DDbackup.
* AliXe - Francisation et personnalisation de SlaX ; CD autonome canadien développé par une Montréalaise qui s'identifie avec l'alias « Alisou », mais qui sur le site du 4Bak reconnait être Sylvie Migneault elle-même ; le CD autonome vise à promouvoir Slackware et SlaX entre les utilisateurs francophones.
* Arudius - utilisé pour tester la sécurité informatique, fondée sur Slackware et Zenwalk.
* Austrumi - par défaut s'installe temporairement dans la mémoire vive ; développé par Andreijs Meinerts et autres.
* BackTrack - distribution suisse fondée sur Slackware et SlaX résultant de la fusion entre Auditor Security Linux et WHAX ; orientée sécurité.
* College - distro suisse qui allègue se fonder sur Debian, mais dont la gestion des paquets est en .tgz.
* DNALinux - argentin fondé sur SlaX.
* eMoviX - italien orienté vers le multimédia. Voir MoviX.
* GoblinX - brésilien qui, installé sur un disque dur, converti les paquets .tgz de Slackware en modules .mo.
* KlaX - allemand clone de SlaX pour la présentation et la promotion de KDE.
* LiveCD Router - argentin dédié à l'opération de réseaux et connexions internet.
* LG3d live-cd - CD autonome de Sun visant à présenter le projet looking glass, basé sur Slax.
* MoviX - italien orienté vers la création de matériel multimédia.
* MoviX² - italien orienté vers le multimédia (exécution).
* MutageniX - Suite de CD autonomes américains.
* Privare - canadien, c'est l'ancien eLearnix, avant FreeLoader Linux ; c'est pratiquement un cours Linux en forme de système opérationnel fondé sur Slackware.
* Puppy - australien basé et compatible avec Slackware 12, léger, pouvant s'installer sur la plupart des médias connectables. Importante équipes de contributeurs et logiciels spécifiques.
* SlAmpp - hollandais fondé sur SlaX mais avec les paquets de Slackware ; indiqué comme une solution simple pour des serveurs personnels.
* SlaX - tchèque fondé sur Slackware et KDE développé par Tomas Matejicek ; installé sur un disque dur ou dans un pendrive, il convertit les paquets .tgz de Slackware en modules .lzm.
* STuX - italien.
* Tereré - brésilien projeté pour les systèmes d'authentification de fournisseurs et de réseaux à la maison de type LAN.
* Wolvix - norvégien basé sur SlaX.
* ZenLive - français basé sur Zenwalk.

Distributions et LiveCDs non désactivés

* DDbackup - devenu 4Bak.
* Drinou - devenu P!tux.
* eLearnix - devenu Privare.
* FreeLoader Linux - devenu Privare.
* MiniSlack - devenu Zenwalk.
* WhaX - devenu iWhaX.

Distributions et LiveCDs semi désactivés

* Litrix Linux - distribution brésilienne qui continue à être active, mais qui à partir de sa version 3.0 a changé Slackware pour Gentoo comme base ; elle est développée par Vagner Rodrigues.

Distributions et LiveCDs désactivés

* BearOps Desktop - distribution canadienne, abandonnée en 2001.
* Buffalo - distribution américaine, abandonnée en 2005.
* Definity - distribution brésilienne développée par une entreprise à Curitiba, PR ; abandonnée en 2003.
* Evil Entity - distribution américaine orientée vers l'édition de multimédia ; abandonnée en 2004, on ne sait pas si son successeur annoncé, Arcano Linux, aie été activé.
* gNox - LiveCD britannique dont la gestion en modules permettrait joindre des modules directement aux images .iso ; distro abandonnée en 2005.
* NetwosiX - distribution italienne orientée vers la sécurité de réseaux ; abandonnée en 2006.
* SentiniX - distribution suédoise orientée vers la sécurité et à la monitoration de réseaux ; abandonnée en 2003.
* Ultima - LiveCD américain qui était développé par Martin Ultima, abandonné en 2005.

Autres distributions et LiveCDs à la philosophie slackée

* Aegean - distribution belge fondée sur Arch Linux.
* Arch - distribution canadienne développée par Judd Vinet, inspirée en Crux Linux.
* Archie - LiveCD malaisien basée sur Arch Linux.
* Crux - distribution suédoise par Per Lidén et autres, avec un système de Ports à la FreeBSD.
* DeLi - distribution allemande développée par Henry Jensen pour des équipements extrêmement anciens, avec le système de Ports à la FreeBSD de Crux Linux et qui encore le met à disposition sous mésure pour Slackware.
* Gobo - distribution brésilienne installable et simultanément LiveCD - selon ce qu'on digite - qui possède un arbre hiérarchique bien à elle.
* Frugalware - Distribution hongroise développée par Miklos Vajna.
* Underground Desktop - Distribution Linux italienne.

Guides et tutoriels utiles

slackware.com : Site officiel
SlackBook : Ce livre devrait être votre première lecture sur Slackware. (LECTURE ESSENTIELLE!)
slackware-fr.orgCommunauté francophone de la Slackware Linux

Articles/Tutoriels

Tutoriels 1 : Compiler ses propres programmes sous Slackware et les installer avec installpkg

Questions fréquemment posées

Q1 : La Slackware inclut plutôt les dernières versions de logiciel ou se veut-elle stable ?
R1 : Sur les CD (6 en tout) ou le DVD, il y a les dernières versions STABLES. En effet, Slackware est axée sur la stabilité. Les logiciels sur le DVD de la Slackware sont testés et sont sûr d'être stable (à quelques rares exceptions).

Par ailleurs, Slackware encourage le fait de compiler à partir des sources. En faisant cela, nous nous assurons d'avoir la dernière version du logiciel. Disons que la nouvelle version du logiciel sort le 1er juillet. Les distributions binaires mettront plus ou moins un (1) mois à inclure la mise à jour alors que nous, nous pourrons le compiler dès le 1er juillet!

Donc, en utilisant les paquets précompilés (binaires), la distribution sera TRÈS STABLE, mais un peu en retard, alors qu'en compilant à partir des sources, le système sera ENCORE PLUS À JOUR QUE LES DISTRIBUTIONS LES PLUS POPULAIRES.

Il ne faut pas oublier que nous pouvons mélanger binaires et sources. Par exemple, installer le système de base avec des logiciels stables et les paquets tels que GIMP, OpenOffice à leur dernière version.

Q2 : Combien de paquets sont disponibles environ (Sans vouloir juger la qualité d'une distribution sur le nombre de paquets) ?
R2 : Ce qu'il faut dire, c'est que le nombre de paquets fournis est pauvre à la base (1011 paquets sur la 13.1, d'après le PACKAGE.TXT). Mais il est très simple de construire ses propres paquets à partir des sources, ce qui permet à terme d'installer les paquets que nous voulons, dans la version que nous désirons, avec les options de compilation que nous voulons. En somme, plus de labeur, mais plus de liberté...

Problèmes et solutions

À vous de remplir cette section!

Galerie photo

Voilà! J'espère que vous apprécierez ce topic!

dodelria

10 juillet 2010 à 0:38:01

Merci de cette petite présentation, j'ai quelques questions au sujet de cette distribution :

- La Slackware inclut plutôt les dernières versions de logiciel ou ce veut-elle stable ?
- Combiens de paquets sont disponible environs (Sans vouloir juger la qualité d'une distribution sur le nombre de paquets) ?
- Retours d'expériences ?

10 juillet 2010 à 2:33:06

Salut dodelria,

Voici les réponses à tes questions :

Citation : dodelria

La Slackware inclut plutôt les dernières versions de logiciel ou ce veut-elle stable ?

Sur les CD (6 en tout) ou le DVD, il y a les dernières versions STABLES. En effet, Slackware est axée sur la stabilité. Si tu veux ABSOLUMENT avoir les dernières versions, regardes du côté de ArchLinux, une distribution qui adhèrent au même principe que Slackware (KISS : keep it simple, stupid), mais qui est en "rolling-release". Certaines personnes disent que Arch est Slackware, mais plus à jour. Pourtant, n'oublie pas qu'être à jour n'est pas toujours bien.... Il peut y avoir des beugs logiciels. Les logiciels sur le DVD de la Slackware sont testés et sont sûr d'être stable (à quelques rares exceptions).

Aussi, Slackware encourage le fait de compiler à partir des sources. En faisant cela, tu t'assures d'avoir la dernière version du logiciel. Disons que la nouvelle version du logiciel sort le 1er juillet. Les distributions binaires mettront plus ou moins 1 mois à inclure la mise à jour alors que toi, tu pourras le compiler dès le 1er juillet!

Donc, si tu utilisent les paquets précompilés (binaires), tu restes d'avoir une distribution TRÈS STABLE, mais un peu en retard, alors que si tu décides de compiler à partir des sources, tu auras un système À JOUR.

N'oublies pas que tu peux mélanger binaires et sources. Par exemple, tu installes le système de base avec des logiciels stables et les paquets tels que GIMP, OpenOffice à leur dernière version.

Citation : dodelria

Combiens de paquets sont disponible environs (Sans vouloir juger la qualité d'une distribution sur le nombre de paquets) ?

Désolé, mais je n'ai pas trouvé le nombre de paquets. En fait, c'est que le "Slackware Package Browser" est en train d'être complétement réécrit pour faciliter l'accès et l'ergonomie... Je n'ai donc plus accès à l'ancien. Tu dois pourtant comprendre que la méthode préconisée par Slackware pour installer les paquets est le DVD de 4 GO (beaucoup de logiciel) et la compilation. Tu as donc théoriquement accès à tous les paquets du monde entier, ou plutôt de la toile entière :lol:

. Le seul obstacle est ta volonté

Citation : dodelria

Retours d'expériences ?

Quoi dire d'autres que J'ADORE!. J'adore le contrôle que Slackware nous donne, que ce soit au niveau des fichiers de configuration ou la compilation des paquets comme JE LE VEUX, j'adore tout simplement.

kna

10 juillet 2010 à 22:44:51

MaitreEauEau > Euh, tu n'es pas obligé de suivre les releases stables. Comme tu peux utiliser sid pour une debian, tu peux utiliser slackware en -current, tu auras des paquets à jour et précompilés, et en rolling-release !

dodelria > Ce qu'il faut dire, c'est que le nombre de paquets fournis est pauvre à la base (1011 paquets sur la 13.1, d'après le PACKAGE.TXT). Mais comme le signale MaitreEauEau, il est très simple de te construire tes propres paquets à partir des sources, ce qui te permet à terme d'installer les paquets que tu veux, dans la version que tu veux, avec les options de compilation que tu veux. En somme, plus de labeur, mais plus de liberté...

11 juillet 2010 à 5:45:09

Il faut aussi rajouter que le truc des distributions comme Debian qui annonce quelque 20 000 paquets est de séparer chaque paquet en "sous-paquet" : pkg-devel, pkg-lib, pkg-... .

Le terme rolling-release désigne une distribution qui n'a pas de version. Si tu vas sur le site de arch, tu verras qu'il n'y a pas de version. Les live CD ne reflètent que les base de données à un certain moment. Slackware a des versions (13.1) et il est plus difficile d'être rolling-release principalement à cause de l'absence (justifiée) de gestionnaire de paquets comme Pacman.

13 juillet 2010 à 22:26:53

Citation : MaitreEauEau

Il faut aussi rajouter que le truc des distributions comme Debian qui annonce quelque 20 000 paquets est de séparer chaque paquet en "sous-paquet" : pkg-devel, pkg-lib, pkg-...

Euh, c’est loin d’être l’explication principale. Même si chaque paquet source empaqueté par Patrick Volkerding donnait lieu à 4 ou 5 paquets Slackware, ça ne ferait jamais qu’environ 5000 paquets, soit toujours beaucoup moins que ce que fournit Debian (au passage, aux dernières nouvelles, le nombre de paquetages chez Debian est aujourd’hui plus proche des 30000 que des 20000).

La différence entre le nombre de paquets entre deux distributions s’explique avant tout par les objectifs et la philosophie de chaque distribution (sur ce point, Debian vise clairement l’exhaustivité — empaqueter le moindre logiciel libre —, ce qui n’est pas du tout dans l’intention de la Slackware).

Citation : dodelria

La Slackware inclut plutôt les dernières versions de logiciel ou ce veut-elle stable ?

Ça dépend de l’humeur de Patrick Volkerding. Il lui est déjà arrivé de mettre à jour un paquetage pour une version majeure fraichement publiée par les développeurs upstream, juste avant de sortir une Release Candidate...

15 juillet 2010 à 23:30:40

TUTORIEL 1 : Comment compiler un programme à partir de ses sources?

Un gros merci à gouttegd pour la correction du tutoriel!

Aperçu

Si vous plongez dans l'univers de Linux depuis quelque temps, vous avez certainement déjà entendu parlé de la légendaire Slackware Linux et de son gestionnaire de paquet qui ne gère pas les dépendances

Pour les nouveaux, ce système doit paraître... :euh:

démodé!

À l'heure des RPM et DEB, comment peut-on utiliser un gestionnaire de paquet qui ne tracke pas les dépendances!? o_O

Tout simplement pour la simplicité, le contrôle, la puissance, la facilité (oui, la facilité -> mise à jour, redistribution, etc), nouvelles versions obtenues plus rapidement, meilleure compréhension du paquet et de Linux... Et la liste n'est pas exhaustive !

Pour obtenir plus d'informations sur POURQUOI LE GESTIONNAIRE DE PAQUET DE SLACKWARE APPORTE SIMPLICITÉ, CONTRÔLE, PUISSANCE ET AUTRES, lisez cet article.

Voici les étapes pour installer un paquet sous Slackware Linux :

Installer un paquet sous Slackware à partir du code source implique les étapes suivantes :

1. Télécharger et décompresser l'archive du code source
2. Configurer le paquet
3. Exécuter make pour construire le programme
4. Exécuter makepkg nom_du_paquet.tgz pour créer le paquet et intallpkg pour installer

Voilà pour l'aperçu! Passer à la prochaine étape, les prérequis :magicien:

Prérequis

Cette section présente les prérequis pour compiler de manière réussie un paquet sous Slackware.

La première chose à avoir est un compilateur! GCC est le compilateur C de GNU/Linux. Vous le trouverez sur le DVD d'installation dans la section développement (D) ou ici.

Ensuite, il vous faudra un environnement de travail ("Building Environment"). Je vous conseille fortement de créer un répertoire dans lequel vous effectuerez chacune de vos compilation.

Certaines personnes installent directement dans /usr/local (je le déconseille)

D'autres créent un dossier dans /home sous le nom de slackware et un groupe 'packager' auquel root et l'utilisateur normal appartienne. Cette méthode est utile parce qu'elle sépare tout ce qui touche au système du dossier de l'utilisateur normal, tout en permettant à ce même utilisateur d'y avoir accès et elle éloigne les dossiers plus sensibles à la modification (par exemple, écrire dans /etc au lieu de /usr/local..) de la portée de l'utilisateur normal qui possèderait les droits root. L'arborescence du dossier /home/slackware ressemblerait à ceci :

/home/slackware
     |
     |_____________ source
                       |
                       |____________ dossier 1(# composé du nom du paquet)
                       |
                       |____________ dossier 2(# composé du nom du paquet)
                       |
                       |____________ dossier 3(# composé du nom du paquet)
     |
     |_____________ packages (# créés par makepkg)
                       |
                       |____________ paquet 1(# composé du nom du paquet)
                       |
                       |____________ paquet 2(# composé du nom du paquet)
                       |
                       |____________ paquet 3(# composé du nom du paquet)

Enfin, j'utilise une méthode que j'aime pour son organisation. Je vous explique par une image :

/home/nom_utilisateur_normal/build
     |
     |_____________ source
                       |
                       |____________ dossier 1(# composé du nom du paquet)
                                         |
                                         |_________ version (1) du paquet (Exemple : 1.1.4)
                                         |
                                         |_________ version (2) du paquet (Exemple : 1.2.0)
                                         |
                                         |_________ current (Pointant vers la version utilisée par le système)
                       |
                       |____________ dossier 2(# composé du nom du paquet)
                                         |
                                         |_________ version (1) du paquet (Exemple : 1.1.4)
                                         |
                                         |_________ version (2) du paquet (Exemple : 1.2.0)
                                         |
                                         |_________ current (Pointant vers la version utilisée par le système)
                       |
                       |____________ dossier 3(# composé du nom du paquet)
                                         |
                                         |_________ version (1) du paquet (Exemple : 1.1.4)
                                         |
                                         |_________ version (2) du paquet (Exemple : 1.2.0)
                                         |
                                         |_________ current (Pointant vers la version utilisée par le système)
     |
     |_____________ packages (# créés using makepkg)
                       |
                       |____________ paquet 1/nom-version.tgz
                       |
                       |____________ paquet 2/nom-version.tgz
                       |
                       |____________ paquet 3/nom-version.tgz

C'est assez explicite, je crois... En gros, chaque programme a son dossier et chaque version de programme est classée dans un dossier. Cela rend possible (et facile) le "downgrade", soit le fait de reculer vers une version antérieure. C'est utile dans le cas où une nouvelle version de programme vient de sortir, ou bien est connue pour être instable.

Étapes

Voici les étapes à suivre, supposant que vous avez créez un système de dossier tel que montrez au prérequis.

1. Télécharger et décompresser l'archive du code source

Vous téléchargez l'archive sur le site du constructeur ou sur un miroir. Ensuite, vous devez décompresser les sources du programmes :

Il y a deux types d'archives couramment rencontré :

tar.gz
tar.bz2

Pour décompresser une archive tar.gz, on utilise la commande suivante : $ tar zxvf archive.tar.gz
Pour décompresser une archive tar.bz2, on utilise la commande suivante : $ tar xvfj archive.tar.bz2

L'archive sera décompressée dans un dossier composé du nom (et parfois de la version) du programme. Vous allez renommer ce dossier comme suit : xarchive.

Vous vous demandez sûrement pourquoi xarchive!

La réponse est simple! xarchive veut dire (e)X(tracted)archive. Donc, si vous comprenez bien, le dossier xarchive contient l'archive extraite.

Vous allez ensuite créer un dossier tree dans lequel le programme sera installé.

Il peut être utile d'exécuter la commande tar tvf avant d'extraire l'archive pour vérifier si, de un, un dossier sera réellement créer et si l'archive ne contient aucun lien absolu (/etc/passwd, /etc/group, par exemple), malgré le fait que si vous n'êtes pas en mode super-utilisateur (root), l'archive ne pourra pas accéder à ces fichiers.

2. Configurer le programme

Il est maintenant temps de configurer notre programme selon nos besoins. Pour connaître les options de compilation disponible, exécuter ./configure --help | less. Ici, je ne peux pas vraiment vous aider puisque chaque paquet à des options différentes... Il faudra lire le fichier et décider quoi activer et qui désactiver. Voici quelques options répandues et souvent importantes :

--prefix=dosier
<puce>--bindir=dossier : Installe les exécutables dans dossier
--sbindir=dossier : Installe les exécutables systèmes dans dossier
--libdir=dossier : Installe les bibliothèques dans dossier
--disable-shared : Prévient le paquet de construire les bibliothèques partagées. Dépendemment de la bibliothèque,cela peut sauver bien des tracas plus tard
--with-paquet=dossier : Indique à configure que paquet est dans dossier

3. Installer le programme

Il ne reste plus qu'à exécuter make && make install DESTDIR=dossier.

Puisque nous ne voulons pas installé le logiciel directement dans notre arborescence root (/), nous devons rediriger l'installation avec l'option "DESTDIR=dossier". Dépendemment de la méthode de travail que vous utilisez, vous devrez remplacer dossier par votre dossier d'installation. Avec ma méthode, vous entreriez make install --DESTDIR=/home/utilisateur/build/source/paquet/version/tree. Cette commande installera l'arborescence de vos paquet en utilisant le dossier tree précédemment créé comme destination pour TOUS mes fichiers. Ainsi, l'utilisation de makepkg sera facilitée. Sinon, vous pouvez taper /tmp/build/.

Si aucune erreur n'est relevée, passez à la prochaine étape!

[ERREUR : SECTION À VENIR!]

4. Créer un paquet reconnu par installpkg

Slackware Linux offre plusieurs programmes pour installer des paquets. Cependant, les paquets doivent être de la bonne extension! Les sources seules ne suffisent pas, et ce, malgré le fait qu'elles aient été compilées. Il faudra donc transformé notre code source compilé en format de paquet reconnu par installpkg.

Saisissez la commande suivante:

cd dossier # dossier étant l'argument passé à DESTDIR lors de make install DESTDIR=dossier
makepkg /home/utilisateur/build/packages/nom-version.tgz # Créé le paquet dans le dossier packages

Voici ce qui s'affichera :

Slackware package maker, version 2.1.

Searching for symbolic links:

No symbolic links were found, so we won't make an installation script.
You can make your own later in ./install/doinst.sh and rebuild the
package if you like.

This next step is optional - you can set the directories in your package
to some sane permissions. If any of the directories in your package have
special permissions, then DO NOT reset them here!

Would you like to reset all directory permissions to 755 (drwxr-xr-x) and
directory ownerships to root.root ([y]es, [n]o)?

Je réponds oui la plupart du temps. Faites tout de même attention : "If any of the directories in your package have
special permissions, then DO NOT reset them here!" (Si un dossier dans ton paquet a des permissions spéciales, alors ne les changent pas ici!).

Maintenant que le paquet est créé, il suffit de cd dans le répertoire de ce dernier et de l'installer avec installpkg!

cd /home/utilisateur/build/packages/
installpkg nom-version.tgz

Et magie, le paquet est installé! :magicien:

16 juillet 2010 à 8:17:38

Citation : MaitreEauEau

À l'heure des RPM et DEB, comment peut-on utiliser un gestionnaire de paquet qui ne tracke pas les dépendances!? Tout simplement pour la simplicité, le contrôle, la puissance, la facilité (oui, la facilité -> mise à jour, redistribution, etc), nouvelles versions obtenues plus rapidement, meilleure compréhension du paquet et de Linux... Et la liste n'est pas exhaustive !

Je suis naturellement d’accord, mais tu n’expliques aucunement en quoi le « gestionnaire de paquet » (entre gros guillemets, il n’y a pas de « gestionnaire » à proprement parler, seulement un concept simple de paquet et les outils qui vont avec pour les manipuler) de Slackware apporte « contrôle, puissance, facilité, etc. » Je doute pourtant fort que ce soit évident pour ceux qui ont (trop) l’habitude des systèmes de paquet bloatés comme RPM ou DEB…

Citation : MaitreEauEau

Installer un paquet sous Slackware (et sous la plupart des distributions) à partir du code source implique les étapes suivantes :

Il faudrait choisir : veux-tu rester générique et parler pour la plupart des distributions (auquel cas un topic dédié à Slackware n’est pas l’endroit approprié), ou bien ne parler que pour Slackware ? Les premières étapes sont communes, mais les deux dernières, la construction du paquet et son installation, sont spécifiques à la Slackware.

Citation : MaitreEauEau

Certaines personnes installent directement dans /usr/local

Pourquoi ne dis-tu pas tout de suite qu’il s’agit d’une mauvaise idée ?

Citation : MaitreEauEau

D'autres créent un dossier dans /home sous le nom de slackware et un groupe 'packager' auquel root et l'utilisateur normal appartienne.

Moui, pourquoi pas, mais quel intérêt ?

Citation : MaitreEauEau

Il peut être utile d'exécuter la commande tar tvf avant d'extraire l'archive pour vérifier si, de un, un dossier sera réellement créer et si l'archive ne contient aucun lien absolu (/etc/passwd, /etc/group)

La présence de noms de fichier absolus dans l’archive ne causera aucun problème, l’utilisateur n’ayant pas le droit d’écrire ailleurs que chez lui ou dans /tmp. Tu ne conseilles tout de même pas d’extraire et compiler les sources sous l’identité du superutilisateur… n’est-ce pas ?

Citation : MaitreEauEau

Il ne reste plus qu'à exécuter make && make install. Si aucune erreur n'est relevée, passez à la prochaine étape!

Il faudrait savoir, là : le but de ton tutoriel est d’installer un programme directement dans l’arborescence du système (via make install), ou bien de créer un paquet Slackware ?

Si le but est d’installer directement, c’est à mon avis une très mauvaise idée, et ce n’est pas la « bonne pratique » habituelle sous Slackware.

Si le but est de créer un paquet, alors il ne faut pas exécuter simplement make install ! Il faut faire une installation « factice » du programme dans une arborescence séparée, à partir de laquelle le paquetage sera construit.

17 juillet 2010 à 3:41:05

Je tiens premièrement à remercier gouttegd pour la révision!

Ensuite :

Citation : gouttegd

Citation : MaitreEauEau
À l'heure des RPM et DEB, comment peut-on utiliser un gestionnaire de paquet qui ne tracke pas les dépendances!? Tout simplement pour la simplicité, le contrôle, la puissance, la facilité (oui, la facilité -> mise à jour, redistribution, etc), nouvelles versions obtenues plus rapidement, meilleure compréhension du paquet et de Linux... Et la liste n'est pas exhaustive !

Je suis naturellement d’accord, mais tu n’expliques aucunement en quoi le « gestionnaire de paquet » (entre gros guillemets, il n’y a pas de « gestionnaire » à proprement parler, seulement un concept simple de paquet et les outils qui vont avec pour les manipuler) de Slackware apporte « contrôle, puissance, facilité, etc. » Je doute pourtant fort que ce soit évident pour ceux qui ont (trop) l’habitude des systèmes de paquet bloatés comme RPM ou DEB…

J'y avais pensé, mais je ne voulais pas encombrer l'article. Ce thème sera abordé dans un post séparé. Si tu veux, tu peux m'aider

Citation : gouttegd

Citation : MaitreEauEau
Certaines personnes installent directement dans /usr/local

Pourquoi ne dis-tu pas tout de suite qu’il s’agit d’une mauvaise idée ?

En quoi est-ce une mauvais idée? J'ai cru comprendre que sur les anciens systèmes Linux et sur UNIX, c'était la manière de faire... Si on sépare /usr/local en dossier : /usr/local/paquet1/ /usr/local/paquet2/, ça marchera aussi bien que /hom/*/build...

Citation : gouttegd

Citation : MaitreEauEau
Il peut être utile d'exécuter la commande tar tvf avant d'extraire l'archive pour vérifier si, de un, un dossier sera réellement créer et si l'archive ne contient aucun lien absolu (/etc/passwd, /etc/group)

La présence de noms de fichier absolus dans l’archive ne causera aucun problème, l’utilisateur n’ayant pas le droit d’écrire ailleurs que chez lui ou dans /tmp. Tu ne conseilles tout de même pas d’extraire et compiler les sources sous l’identité du superutilisateur… n’est-ce pas ?

Il arrive d'oublier ou d'être distrait... :-°

Citation : gouttegd

Citation : MaitreEauEau
Il ne reste plus qu'à exécuter make && make install. Si aucune erreur n'est relevée, passez à la prochaine étape!

Il faudrait savoir, là : le but de ton tutoriel est d’installer un programme directement dans l’arborescence du système (via make install), ou bien de créer un paquet Slackware ?

Si le but est d’installer directement, c’est à mon avis une très mauvaise idée, et ce n’est pas la « bonne pratique » habituelle sous Slackware.

Si le but est de créer un paquet, alors il ne faut pas exécuter simplement make install ! Il faut faire une installation « factice » du programme dans une arborescence séparée, à partir de laquelle le paquetage sera construit.

** EDIT **
J'avais oublié de spécifier --prefix=/home/*/build/source/pkg/version/tree, je l'ai rajouté
*/ EDIT **

En fait, il y a une petite astuce

Si tu lis avant, tu verras que lors de la configuration, je spécifie le dossier d'installation : ./configure --prefix=/home/*/build/source/pkg/ver/tree . Ainsi, lorsque j'exécute make && make install, les fichiers ne vont pas dans /, ce qui constituerait une mauvaise pratique, effectivement, mais dans le dossier tree (arborescence) qui contient justement l'arborescence du paquet. Il suffit de migrer vers ce répertoire et d'exécuter makepkg pour installer le paquet!

Mais, serait-il préférable d'exécuter ./configure --prefix=/usr et make install DESTDIR=[...] ?

Citation : gouttegd

Citation : MaitreEauEau
D'autres créent un dossier dans /home sous le nom de slackware et un groupe 'packager' auquel root et l'utilisateur normal appartienne.

Moui, pourquoi pas, mais quel intérêt ?

C'est vrai, mais en même temps, je veux que l'utilisateur essaie différent environnement de travail et décide celui qu'il préfère... J'ai tout de même ajouté une description plus élaborée. Merci.

Merci encore!

17 juillet 2010 à 19:29:27

Citation : MaitreEauEau

En quoi [installer directement dans /usr/local est] une mauvais idée?

Parce que tout ce que tu y installeras de cette manière sera hors de contrôle du gestionnaire de paquet, quel qu’il soit (sous Slackware ou n’importe quelle autre distribution), ce qui rendra délicat la désinstallation ou la mise à jour de ces logiciels.

Installer chaque logiciel dans un sous-dossier séparé régle ce problème, mais en introduit un autre : à chaque installation, il faudra modifier les variables d’environnement PATH, LD_LIBRARY_PATH, MANPATH, etc., pour y ajouter les sous-dossiers bin/, lib/, man/, etc. dans le sous-dossier nouvellement créé. Faisable, mais fastidieux.

Créer un paquet et l’installer dans l’arborescence normale du système (les fichiers de config dans /etc, les exécutables dans /usr/bin, les bibliothèques dans /usr/lib, les pages de manuel dans /usr/man, etc.) est vraiment LA méthode la plus propre et la plus efficace (elle n’est éventuellement battue que par la méthode consistant à installer les logiciels dans son propre répertoire personnel, notamment à des fins de test), quelle que soit la distribution. Sous Slackware, c’est en plus une méthode très facile, compte tenu de la grande simplicité du concept de paquet.

Citation : MaitreEauEau

lors de la configuration, je spécifie le dossier d'installation : ./configure --prefix=/home/*/build/source/pkg/ver/tree. [...] Mais, serait-il préférable d'exécuter ./configure --prefix=/usr et make install DESTDIR=[...] ?

Ce n’est pas préférable, il faut procéder ainsi, et surtout pas utiliser --prefix pour spécifier l’arbre temporaire d’installation !

La plupart des programmes qui ont besoin de charger un fichier de ressources (messages, iĉones, spécification d’interface graphique au format libglade, données diverses, etc.) vont le chercher dans un répertoire dont le nom sera construit, à la compilation, à partir de la valeur de l’option --prefix. Cette option doit donc représenter la racine de l’arborescence où le programme sera véritablement installé, et non une arborescence temporaire qui n’existe que le temps de construire le paquet.

Si tu as utilisé ta méthode jusqu’à présent, et que tous les logiciels que tu as empaqueté fonctionnent sans problème, tu as eu beaucoup de chance.

18 juillet 2010 à 1:01:06

Bonjour à tous,

Sur ce site il dise de mettre les logiciels dans "usr/local"...ca veut dire que ce site est mauvais, ou moi qui ne comprend rien??
Parce que c'est vraiment pas claire je trouve, je ne sais toujours pas quelle est la bonne méthode.

Anonyme

18 juillet 2010 à 1:26:24

Citation

Il faut cependant prendre garde car certains éléments ne sont pas toujours localisés par le système lorsqu'ils sont dans ce répertoire.

Donc non, ce site n'est pas complétement mauvais. De toute façon, le système de paquets de Slackware est tellement flexible que chacun fait un peu comme il le sent.
Quant au "Tuto", il m'aurait paru plus intéressant de montrer comment créer des SlackBuilds (même si ça consiste juste à replacer la manipulation que tu as décrite dans un script et quelques lignes de descriptions). Un passage sur comment les utiliser me paraît aussi intéressant car ton tuto donne l'impression qu'il est toujours nécessaire d'effectuer cette opération pour chaque paquet que l'on souhaite installer, ce qui est plutôt long si ajoute à cela la recherche et l'installation des dépendances.

18 juillet 2010 à 3:14:00

Merci pour vos contributions à tous!

Citation : Mr.Tambourine

Quant au "Tuto", il m'aurait paru plus intéressant de montrer comment créer des SlackBuilds (même si ça consiste juste à replacer la manipulation que tu as décrite dans un script et quelques lignes de descriptions). Un passage sur comment les utiliser me paraît aussi intéressant car ton tuto donne l'impression qu'il est toujours nécessaire d'effectuer cette opération pour chaque paquet que l'on souhaite installer, ce qui est plutôt long si ajoute à cela la recherche et l'installation des dépendances.

Je crois plus prioritaire de savoir comment compiler un programme "à la dure" avant d'utiliser les SlackBuilds, mais effectivement, un tuto sur les SlackBuilds serait très intéressant (à venir donc

Citation : neo2500

Bonjour à tous,

Sur ce site il dise de mettre les logiciels dans "usr/local"...ca veut dire que ce site est mauvais, ou moi qui ne comprend rien??
Parce que c'est vraiment pas claire je trouve, je ne sais toujours pas quelle est la bonne méthode.

En fait, la meilleure méthode est celle qui marche pour toi! C'est ça Slackware

Tous les tutos que tu trouveras sur le net ne feront que te guider, tu devras testé les méthodes et voir celle(s) qui te plai(sen)t. Et puis, après tout, qui sommes-nous pour dire qu'une méthode est meilleure qu'une autre?! :euh:

Aussi, je crois que tu as mal lu...

Citation : lien de neo2500

La compilation terminée, il va nous falloir installer le binaire. La commande standard d'installation, make install, a pour effet de mettre les fichiers compilés dans le répertoire préfixé, pour ce qui nous concerne /usr/local. Outre le fait que nous n'avons pas les droits (seul le superutilisateur peut écrire dans /usr/local), nous voulons faire un paquet en préalable à toute installation. C'est pourquoi il va d'abord falloir rediriger l'installation vers un dossier temporaire : un dossier différent de la destination finale et sur lequel nous aurons les droits nécessaires. Pour ce, il existe la variable DESTDIR=<répertoire>13) qui permet de moduler make install :

Comme dans mon tuto, ils disent de redigier l'installation vers un répertoire temporaire.

Citation : gouttegd

Créer un paquet et l’installer dans l’arborescence normale du système (les fichiers de config dans /etc, les exécutables dans /usr/bin, les bibliothèques dans /usr/lib, les pages de manuel dans /usr/man, etc.) est vraiment LA méthode la plus propre et la plus efficace (elle n’est éventuellement battue que par la méthode consistant à installer les logiciels dans son propre répertoire personnel, notamment à des fins de test), quelle que soit la distribution. Sous Slackware, c’est en plus une méthode très facile, compte tenu de la grande simplicité du concept de paquet.

Pour utiliser makepkg (qui facilite la maintenance des logiciels compilés selon moi), ne faut-il pas avoir l'arborescence du programme ?
Si les fichiers utilisés par le programme (soit son arborescence) se mélange à l'arborescence /, makepkg sera inutilisable... non?

Exemple :

Paquet : mutt
Version : 1.7.20

Ma méthode :

Répertoire du programme : /home/*/build/source/mutt/1.7.20/
Répertoire d'installation spécifié par make install : DESTDIR=/home/*/build/source/mutt/1.7.20/tree

Une fois que l'arborescence de mutt est installée dans */tree, je cd à l'intérieur et exécute makepkg. J'installe ensuite grace à installpkg et désinstalle avec removepkg.

Simple... non?

De plus, ce répertoire N'EST PAS TEMPORAIRE!
/home/*/build/source/mutt/1.7.20/ restera là pour toujours (J'ai assez d'espace disque pour cela !). Ainsi, je n'ai qu'à exécuter :

cd /home/*/build/source/mutt/1.7.20/xarchive #xarchive étant l'archive extraite du programme (contenant le Makefile)
make uninstall

Pour désinstaller le programme "proprement".

Un autre avantage est que mon système permet de downgrader et upgrader à volonté. En effet, si la nouvelle version de mutt 1.8.1 sort, je n'ai qu'à créer un dossier /home/*/build/source/mutt/1.8.1 (et garder le dossier 1.7.20). J'aime bien aussi symlinker la nouvelle version à "current".

Citation : gouttegd

Citation : MaitreEauEau
lors de la configuration, je spécifie le dossier d'installation : ./configure --prefix=/home/*/build/source/pkg/ver/tree. [...] Mais, serait-il préférable d'exécuter ./configure --prefix=/usr et make install DESTDIR=[...] ?

Ce n’est pas préférable, il faut procéder ainsi, et surtout pas utiliser --prefix pour spécifier l’arbre temporaire d’installation !

La plupart des programmes qui ont besoin de charger un fichier de ressources (messages, iĉones, spécification d’interface graphique au format libglade, données diverses, etc.) vont le chercher dans un répertoire dont le nom sera construit, à la compilation, à partir de la valeur de l’option --prefix. Cette option doit donc représenter la racine de l’arborescence où le programme sera véritablement installé, et non une arborescence temporaire qui n’existe que le temps de construire le paquet.

Si tu as utilisé ta méthode jusqu’à présent, et que tous les logiciels que tu as empaqueté fonctionnent sans problème, tu as eu beaucoup de chance.

Comme j'ai dit plus haut, je garde mes arborescences (et non un dossier temporaire), c'est donc surement pour ça que "j'ai eu de la chance".

A+

18 juillet 2010 à 9:39:27

Citation : MaitreEauEau

Pour utiliser makepkg (qui facilite la maintenance des logiciels compilés selon moi), ne faut-il pas avoir l'arborescence du programme ?
Si les fichiers utilisés par le programme (soit son arborescence) se mélange à l'arborescence /, makepkg sera inutilisable... non?

L’arborescence du programme n’est « mélangé » à l’arborescence du système qu’après l’installation. make install DESTDIR=/tmp/package installe l’arborescence du programme dans le dossier /tmp/package, sur lequel tu appelles makepkg.

Citation : MaitreEauEau

Ma méthode :

Répertoire du programme : /home/*/build/source/mutt/1.7.20/
Répertoire d'installation spécifié par make install : DESTDIR=/home/*/build/source/mutt/1.7.20/tree

Une fois que l'arborescence de mutt est installée dans */tree, je cd à l'intérieur et exécute makepkg. J'installe ensuite grace à installpkg et désinstalle avec removepkg.

Simple... non?

Non, tordu.

Si le programme n’est jamais installé à la racine du système et reste dans un dossier bien à lui, quel est l’intérêt de créer un paquetage ? Tu peux le supprimer simplement en supprimant le dossier, l’utilisation de installpkg / removepkg n’apporte rien de plus.

D’ailleurs tu ne sembles même pas utiliser removepkg :

Citation : MaitreEauEau

Ainsi, je n'ai qu'à exécuter :
cd /home/*/build/source/mutt/1.7.20/xarchive #xarchive étant l'archive extraite du programme (contenant le Makefile)
make uninstall
Pour désinstaller le programme "proprement".

Alors, quel est l’intérêt de tout ça ?

Citation : MaitreEauEau

En effet, si la nouvelle version de mutt 1.8.1 sort, je n'ai qu'à créer un dossier /home/*/build/source/mutt/1.8.1 (et garder le dossier 1.7.20). J'aime bien aussi symlinker la nouvelle version à "current".

On a inventé un truc assez sympatoche qui s’appelle des systèmes de contrôle de version…

18 juillet 2010 à 13:34:58

Bonjour,

J'ai plusieurs questions sur Slackware;
J'ai déjà testé une slackware, ce que j'avais aimé c'était qu'on faisait tout nous même, donc si il y a un problème généralement on ne cherche pas bien longtemps.
De plus on configure tout en bash(même les slackbuilds), ce qui unifie tout, ce qui fait que slackware est simple à configurer.

Mes questions portent surtout sur la gestion des paquets.
En effet slackware n'a pas de gestion des dépendances, ce qui n'est pas trop grave.
Mais si j'installe pleins de logiciels, et je me retrouve avec pleins de paquets inutiles, est-il possible de faire un script pour les supprimer par exemple?

Ma deuxième question se porte sur l'installation de paquet "hors distribution" (qui ne sont pas intégrés).
J'ai beaucoup de mal à comprendre, comment on fait une installation de façon "slackware", propre, beaucoup de personnes disent des choses différentes...

Si non je suis allé sur "LinxQuestions.org", les liens sont très intéressant, mais je n'en ai pas trouvé un sur l'installation des paquets, chose que j'ai beaucoup de mal à appréhender.( pas que je ne serais pas le faire, mais plutôt de le faire bien).

18 juillet 2010 à 15:35:11

@gouttegd > Comment est-ce que tu installes toi? Je ne comprends pas... Tu dis créer un paquet avec makepkg, mais tu installes dans la racine? Pourrais-tu m'énumérer les étapes que tu effectues s'il te plait.

@neo2500 > "En effet slackware n'a pas de gestion des dépendances, ce qui n'est pas trop grave. Mais si j'installe pleins de logiciels, et je me retrouve avec pleins de paquets inutiles, est-il possible de faire un script pour les supprimer par exemple?"

Évidemment que oui, c'est possible de faire un script! C'est slackware, pas Ubuntu, n'oublies pas! =P Mais si tu gères bien l'installation de paquet, tu ne devrais pas avoir de "paquets inutiles".

@neo2500 > "Ma deuxième question se porte sur l'installation de paquet "hors distribution" (qui ne sont pas intégrés).
J'ai beaucoup de mal à comprendre, comment on fait une installation de façon "slackware", propre, beaucoup de personnes disent des choses différentes..."

Et bien... c'est un peu ce que j'explique dans le tutoriel plus haut.

Anonyme

18 juillet 2010 à 17:15:23

Citation : MaitreEauEau

@neo2500 > "En effet slackware n'a pas de gestion des dépendances, ce qui n'est pas trop grave. Mais si j'installe pleins de logiciels, et je me retrouve avec pleins de paquets inutiles, est-il possible de faire un script pour les supprimer par exemple?"

Évidemment que oui, c'est possible de faire un script! C'est slackware, pas Ubuntu, n'oublies pas! =P Mais si tu gères bien l'installation de paquet, tu ne devrais pas avoir de "paquets inutiles".

Sa question c'est ça : imaginons que tu installes Firefox, et toutes ses dépendances. Ensuite, tu te dis que tout de même, Firefox c'est lourd et tu le désinstalles. Y-a-t-il un outil pour désinstaller automatiquement les dépendances de Firefox devenues inutiles ?

18 juillet 2010 à 19:09:09

Citation : MaitreEauEau

Évidemment que oui, c'est possible de faire un script! C'est slackware, pas Ubuntu, n'oublies pas! =P Mais si tu gères bien l'installation de paquet, tu ne devrais pas avoir de "paquets inutiles"

Cf la remarque de Tuxicomane. Je sais comment installer un paquet, et les dépendances avec;

Citation : MaitreEauEau

Et bien... c'est un peu ce que j'explique dans le tutoriel plus haut.

Certe, mais par exemple, Gouttegd n'est pas trop d'accord.
Sur un magazine (le linux pratique HS Juin/Juillet 2010) il dise de faire (en gros)

configure -prefix=/opt/NomLogiciel/Version/
make
make install

Finalement il y a pleins de méthodes, mais le plus intéressant est le pourquoi et le comment, pour se faire son opinion.

kna

18 juillet 2010 à 20:49:18

Citation : neo2500

Mais si j'installe pleins de logiciels, et je me retrouve avec pleins de paquets inutiles, est-il possible de faire un script pour les supprimer par exemple?

C'est l'inconvénient de ne pas avoir de gestion de dépendances, il faut que tu saches quelles dépendances tu as installé quand tu veux virer un paquet. Cependant, comme dit plus haut, les paquets ne sont pas divisés comme sur d'autres distib en paquet-bin, paquet-dev, paquet-doc, etc. On est loin de se retrouver avec des arbres de dépendances aussi complexe.

Citation : neo2500

Finalement il y a pleins de méthodes, mais le plus intéressant est le pourquoi et le comment, pour se faire son opinion.

Ben, le principe est simple. Les arborescences alternatives (/usr/local, /opt, ou /home/user/truc) sont utiles lorsque tu veux installer un logiciel sans passer par un paquet slackware, ça reste « à part » dans le système, et tu peux le désinstaller/mettre à jour facilement). Si tu utilises le gestionnaire de paquet, alors il vaut mieux l'installer dans /usr comme les autres, pour éviter les problèmes inhérents à avoir des softs installés n'importe où (variables *PATH entre autres).
Ce n'est pas valable que sous slackware, d'ailleurs...

18 juillet 2010 à 22:08:10

Citation : MaitreEauEau

Comment est-ce que tu installes toi? Je ne comprends pas... Tu dis créer un paquet avec makepkg, mais tu installes dans la racine? Pourrais-tu m'énumérer les étapes que tu effectues s'il te plait.

J’écris un SlackBuild qui compile et installe le logiciel dans une arborescence temporaire (par défaut dans /tmp/build/nom_du_paquet, mais peu importe), appelle makepkg pour créer un paquet depuis cette arborescence, puis supprime l’arborescence qui ne sert plus à rien.

Le tout sous ma propre identité, même pour la création du paquet (comme beaucoup de slackers francophones, ce en quoi nous nous démarquons, par exemples, des slackers de slackbuilds.org, qui exécutent leurs SlackBuilds sous root).

Une fois construit, le paquet peut être installé comme n’importe quel autre paquet Slackware, avec installpkg. C’est à ce moment-là seulement que les fichiers sont installés dans l’arborescence du système.

Plus techniquement, pour les projets autoconfisqués, l’étape de configuration, compilation et installation ressemble dans les grandes lignes à ça :

./configure \
  --prefix=/usr \                   # les sources sont configurées pour une installation "system-wide"
  --libdir=/usr/lib$LIBDIR_SUFFIX \ # bibliothèques dans /usr/lib ou /usr/lib64 selon l’architecture
  --sysconfdir=/etc                 # fichiers de configuration dans /etc, non dans /usr/etc
make
make install DESTDIR=/tmp/build/nom_du_paquet

Citation : Tuxicomane

Sa question c'est ça : imaginons que tu installes Firefox, et toutes ses dépendances. Ensuite, tu te dis que tout de même, Firefox c'est lourd et tu le désinstalles. Y-a-t-il un outil pour désinstaller automatiquement les dépendances de Firefox devenues inutiles ?

Non.

C’est à l’administrateur de tenir les comptes de ce qu’il installe et de ce qu’il peut désinstaller. Après, à chacun sa technique pour mettre ça en œuvre.

Citation : neo2500

Certe, mais par exemple, Gouttegd n'est pas trop d'accord.

C’est surtout que je ne comprends pas la, ou plutôt les méthodes de MaitreEauEau, qui parle tantôt de créer un paquet, tantôt d’installer directement ; qui configure les sources tantôt avec --prefix=/usr, tantôt avec --prefix=/home/build/source/nom/version/tree, qui n’est pas un répertoire temporaire même si on crée un paquetage avec ; utilise tantôt DESTDIR, tantôt non… Je m’y perds, moi.

Citation : neo2500

Sur un magazine (le linux pratique HS Juin/Juillet 2010) il dise de faire (en gros)
configure -prefix=/opt/NomLogiciel/Version/
make
make install

C’est une méthode qui a l’avantage de permettre de désinstaller / mettre à jour les logiciels facilement (puisque chaque logiciel est dans son répertoire, aucun risque de semer le désordre dans les fichiers d’un autre logiciel ou pire dans les fichiers du système).

Elle a deux gros inconvénients :

a) Les fichiers sont installés dans des répertoires non-standards. Les exécutables ne sont pas dans les répertoires où le shell les cherche, les bibliothèques ne sont pas dans les répertoires où le chargeur les cherche, les en-têtes ne sont pas dans les répertoires où le compilateur les cherche, les pages de manuel ne sont pas les répertoires où man les cherche, etc. À chaque installation (ou mise à jour), il faut renseigner correctement les variables PATH, LD_LIBRARY_PATH, MANPATH, etc.

b) Il ne subsiste aucune trace des commandes utilisées pour configurer et compiler le logiciel, qu’il peut pourtant être utile de conserver.

18 juillet 2010 à 22:24:48

Citation : gouttegd

Non.

C’est à l’administrateur de tenir les comptes de ce qu’il installe et de ce qu’il peut désinstaller. Après, à chacun sa technique pour mettre ça en œuvre.

En réalité je ne cherchais pas un outil.
En fait je pensais à faire un truc dans le genre,
A chaque fois que j'installe un logiciel je met à jour un fichier qui auras la forme suivante:

paquet-1
   dependance-1
   dependance-2
paquet-2
   dependance-3

Maintenant, imaginons je veut supprimer paquet-1;
Je regarde les dépendances que j'ai installées, je regarde si elles sont utile ou non pour d'autres paquets, et je désinstalle en conséquence récursivement avec la même méthode.
Si je veut supprimer dépendance-1, alors je met une erreur comme quoi ce paquet est utile pour paquet-1.

18 juillet 2010 à 22:31:57

C’est à ce genre de truc que je pensais quand je disais que chacun met en œuvre sa propre technique.

Anonyme

18 juillet 2010 à 23:26:19

Exactement le genre de réponse que j'attendais, chouette. Bon allez la prochaine fois que je voudrais jouer à construire des châteaux de cartes avec les outils GNU, je ferais un tour chez l'ami Patrick.

21 juillet 2010 à 22:36:59

Bonjour, jaimerais savoir comment installer Xorg (de maniere propre) sur Slackware.

Le fait est que je nai pas installe Xorg lors de linstallation (jai donc seulement la console - ce que jaime, soit dit en passant).
Je cherche sur google, mais il ne semble ny avoir aucun tuto la dessus.

Merci

PS : Desole pour le manque daccent et dapostrophe, je suis en clavier US.

21 juillet 2010 à 22:45:03

Les paquets fournis dans x/ ne sont pas suffisamment propres à ton goût ?

Bon, ben comme je le laissais sous-entendre tous les paquets relatifs à X.org sont dans le répertoire x , dans le répertoire principal de la distribution.

Méthode simple et efficace : installer tout (installpkg x/*.txz).

Si tu veux savoir plus précisément ce que tu installes, les différents composants sont :
– xorg-server
– toutes les bibliothèques (libXmachin)
– les drivers (xf86-type-bidule)
– au moins une partie des polices (font-chose)
– divers programmes allant de l’inutile (xeyes) à l’indispensable (xterm).

22 juillet 2010 à 2:09:47

Ok, merci.

C'est ce que j'allais faire, mais je je demandais seulement s'il existait une façon (par exemple un projet) pour installer seulement les paquets indispensables a l'exécution de x.

Merci

22 juillet 2010 à 9:16:27

Oh, il existe une méthode pour ça : se farcir la liste détaillée des composants de X.org, trier ce qui est indispensable de ce qui l’est moins, et sélectionner les paquets à installer en conséquence.

La section « Dessine-moi un pingouin » du document Linux From Slack adopte la démarche inverse, et indique les paquets les moins indispensables.