Sommaire
- Sa philosophie peut être résumée en KISS (Keep it simple, Stupid!) qui vise à éliminer toute complexité non nécessaire.
- Une forte personnification via son créateur et mainteneur principal.
- Slackware est aussi une distribution qui ne se prend pas la tête et qui a su rester jeune.
- Un bon gestionnaire de paquets.
- Les mises à jour.
Et oui, depuis le 16 juillet, cela fait 18 ans que Patrick Volkerding a réalisé la version 1.0 de la Slackware, la plus vieille distribution encore maintenue de nos jours. Je sais bien que je suis à la bourre, mais mieux vaut tard que jamais. Au-début je voulais m'arrêter là, mais comme ceci est mon premier journal j'ai développé un peu (désolé aux familles …).
Quelques points forts de cette distribution qui expliquent que malgré son âge avancé (en temps informatique) elle a toujours autant de succès et est toujours dans le top 10 de distrowatch.
Sa philosophie peut être résumée en KISS (Keep it simple, Stupid!) qui vise à éliminer toute complexité non nécessaire.
Ici, pas de pam, pulseaudio, systemd ou autre gadget. Un logiciel est incorporé dans la distribution que lorsqu'il marche et s'il apporte vraiment quelque chose. Il n'y a pas non plus de date de sortie imposée par des problèmes de marketing et elle sort quand elle est prête (mais plus souvent que Debian).
D'une version à l'autre, l'administrateur n'est pas dépaysé par les nouveautés qu'il n'a pas demandé.
Une forte personnification via son créateur et mainteneur principal.
En effet, on ne peut pas vraiment comprendre son histoire sans parler du grand gourou Patrick Volkerding ou Pat. C'est lui qui pendant longtemps a été le seul maître à bord, même si comme dit lors de la sortie de la version 13.1 il y a maintenant plus de gens qui participent.
Slackware est aussi une distribution qui ne se prend pas la tête et qui a su rester jeune.
Dès sa création, le nom choisit est dérivé de Slack, le St Graal de la secte Church of the Subgenius. Ensuite, alors qu'il y avait une escalade de la numération entre les distributions, Pat décide de passer de la version 4 à la version 7 pour se moquer de cette course (quand est-ce que lynx passe de la version 2.8 à la version 11?). Finalement, la dernière réalisée est la 13.37 soit leet.
Un bon gestionnaire de paquets.
KISS est aussi appliqué au gestionnaire de paquet. C'est le seul gestionnaire de paquet qui assure grave depuis 18 ans! Il s'occupe d'installer et de désinstaller les paquets de manière simple et efficace à partir d'une source locale :
installpkg nom.t?z pour installer un paquet
removepkg nom.t?z pour le désinstaller
upgradepkg nom.t?z pour le mettre à jour
Comme ses utilisateurs se font vieux, il existe maintenant pour les feignants slackpkg qui permet d'installer/désinstaller/… à partir d'un dépôt distant :
slackpkg install nom
slackpkg remove nom
slackpkg upgrade nom
slackpkg upgrade-all pour mettre à jour toute la distribution
Pendant ce temps, voyons ce que fait la concurrence d'après la doc :
Sous Debian il y a d'après la FAQ dpkg < apt < aptitude < synaptic et tasksel, mais la FAQ n'explique pas comment utiliser ce dernier. Et si ce n'est pas asses compliqué, on peut utiliser dselect qui est obsolète et non recommandé sur les distributions modernes. Il y a aussi dpkg-deb et dpkg-split. Bref pas facile de s'y retrouver.
Pour les .rpm il existe plusieurs versions dont une qui serait morte. On ne peut pas dire que la commande rpm soit très explicite :
rpm -i nom.rpm pour installer. Attention, -i peut aussi désigner le texte décrivant le paquet selon le contexte (-ivh ou -qilp).
rmp -U nom.rpm (pourquoi une majuscule ?)
rpm -e nom pour désinstaller (e comme …)
De toute façon sous fedora il vaut mieux utiliser yum qui est à peu près aussi simple que slackpkg.
Les mises à jour.
Autre tour de force de Slackware : proposer des mises à jour jusqu'à la version 8.1 (sortie le 19 juin 2002) pour certains programmes comme bind. Comme Pat ne modifie pas les logiciels tant que l'upstream (je n'ai pas trouvé de terme plus adéquat) fait des mises à jour il les applique à la Slack.
De plus, en suivant les instructions CHANGES_AND_HINTS.TXT et UPGRADE.TXT il est possible de suivre les changements de version sans casser son système.
Bref, joyeux anniversaire Slackware et bonne continuation!
Have fun!
# Troll gratuit
Posté par erdnaxeli (site web personnel) . Évalué à 10.
J'ai pertinenté, mais quand même ce troll gratuit est bien dommage.
Et puis de tout façon tout le monde sait que le meilleur gestionnaire de paquet est portage.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Troll gratuit
Posté par Victor . Évalué à 10.
Tu veux dire pacman ?
[^] # Re: Troll gratuit
Posté par Bruce Le Nain (site web personnel) . Évalué à 8.
Parce que tu n'as repéré qu'un seul troll ? :D
# Upstream
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
« Upstream » se dit « amont », en français. Selon le contexte, ça donnes des expression comme « les développeurs amont » ou « la version amont ».
[^] # Re: Upstream
Posté par Gui13 (site web personnel) . Évalué à 8.
À qui?
[^] # Re: Upstream
Posté par ナイコ (site web personnel) . Évalué à 4.
A "On".
[^] # Re: Upstream
Posté par Frank-N-Furter . Évalué à 5.
Quoi, ma sœur est un thon?
Depending on the time of day, the French go either way.
[^] # Re: Upstream
Posté par zebra3 . Évalué à 9.
Et le mec, il lui dit c'est le phare à "On"…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Upstream
Posté par Jeanuel (site web personnel) . Évalué à 4.
C'est pas faux
[^] # Re: Upstream
Posté par B16F4RV4RD1N . Évalué à 6.
sauf que amont est un nom, pas un adjectif. Pour l'utiliser comme tu le fais, il faudrait plutôt dire « les développeurs en amont ».
La seule fois où ça peut se dire ainsi, c'est pour les orgues amont ;)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# DEB
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
tasksel est fait pour l'installateur. C'est une interface de sélection de paquets, concurrente en cela à aptitude, synaptic et dselect qui est caduque.
Rien à voir, dpkg-deb c'est pour inspecter, manipuler des paquets sans les installer. Quant à dpkg-split, je n'en avais jamais entendu parler, mais il a encore moins à voir, il sert à couper des paquets en plusieurs morceaux pour les transférer sur des disquettes trop petites pour les accueillir en entier.
[^] # Re: DEB
Posté par barmic . Évalué à 10.
Déjà considérer une FAQ comme une documentation c'est fort, mais en plus considérer le fait d'avoir plusieurs commandes comme une complexité ça montre juste qu'on est vendredi.
Au passage pour les usages sus-cités Debian n'a que 2 commandes (dpkg et apt-get) là où slack en a 4 (installpkg, removepkg, upgradepkg et slackpkg). Du coup pour avoir la doc dans Debian c'est réunis dans deux pages man là où il faut en lire 4 pour slack.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: DEB
Posté par Jérôme Pinot (site web personnel) . Évalué à 3.
Sous Slackware, tu peux aussi simplement lancer pkgtool qui te permet de tout faire avec une interface ncurses :
Alors oui, c'est basique et ça ne gère pas les dépendances, mais c'est la philosophie de la distribution.
[^] # Re: DEB
Posté par Tonton Th (Mastodon) . Évalué à 8.
La légende selon quoi on pourrait tout faire avec aptitude serait-elle une légende ?
[^] # Re: DEB
Posté par Sano . Évalué à 9.
La question est toujours débattue un peu partout en fait.
Alors de mémoire, aptitude était recommandé pour la gestion quotidienne des paquets depuis Sarge je crois, car il disposait d'une meilleure gestion des dépendances.
À l'époque, apt par exemple ne savait pas désinstaller les packages installés en tant que dépendances si les paquets qui en dépendaient avaient tous été supprimés.
Aptitude lui savait gérer cela.
D'ailleurs, il était aussi déconseillé d'utiliser les 2 en parallèle, car cela pouvait entrainer de problèmes dans la gestion des dépendances.
Maintenant, ce n'est plus le cas, mais aptitude reste plus pratique sur plein de points notamment la possibilité de gérer les paquets plus simplement depuis la même commande, et permet aussi une gestion plus fine des dépendances.
Pour citer la FAQ Debian à ce sujet :
http://www.debian.org/doc/FAQ/ch-pkgtools.en.html
et
Donc en résumé, les recommandations officielles de Debian sont :
- aptitude pour la gestion quotidienne des packages
- apt-get pour les installations et mises à jour majeures
*Sano*
[^] # Re: DEB
Posté par Tonton Th (Mastodon) . Évalué à 2.
La frontière entre les deux me semble assez floue, et dans quel camp faut-il classer synaptic ? C'est pas très clair, tout ça...
[^] # Re: DEB
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Ils sont tous interchangeables, comme peuvent l'être Iceweasel, Chromium et Epiphany.
[^] # Re: DEB
Posté par coïn . Évalué à -6.
donc il y en a un de trop. à minima
[^] # Re: DEB
Posté par BFG . Évalué à 2.
au minimum
[^] # Re: DEB
Posté par claudex . Évalué à 3.
Synaptic, c'est à utiliser quand tu as besoin d'une interface graphique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: DEB
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
aptitude a aussi une interface graphique (en ncurse)
[^] # aptitude vs apt-get, une différence
Posté par Arthur Accroc . Évalué à 2.
Alors, pour avoir vu le cas sur une Ubuntu : si ton système n’est pas vraiment à jour et que tu as besoin d’ajouter un paquet, aptitude voudra tout te mettre à jour, tandis qu’apt-get, non.
Si tu as une bonne connexion, je te conseillerais donc aptitude (comme ça, pas de risque d’avoir des problèmes avec des dépendances un peu trop vieilles), mais si tu es sur une connexion pourrie et que tu as besoin de ton logiciel rapidement, surtout pas !
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: DEB
Posté par Altor . Évalué à 1.
Si j'ai regardé la FAQ c'est parce qu'il y a plusieurs commandes qui font la même chose (gérer les paquets) et que je ne savais pas laquelle il fallait prendre. De plus, ça permettait de voir l'évolution du gestionnaire sur 18 ans. Là où Slackware utilise toujours les pkgtools, Debian a essayé plusieurs systèmes sans que ce ne soit forcement très clair (cf. les différentes discussions sur ce site). Pour moi, ce n'est ni KISS ni dans la philosophie unix (un outil pour une tâche).
Slackware a aussi évolué. On est passé du .tgz au .txz avec compression lzma pour de meilleure performance, on utilise slackpkg pour la mise à jour de la distribution à travers le réseau et sbopkg pour installer les programmes non-officiels à partir des slackbuilds. Mais on peut utiliser installpkg et slackpkg ensemble sans casser le système. Les nouveaux outils ne remettent pas en cause les anciens et simplifient juste certaines tâches administratives.
[^] # Debian vs KISS
Posté par Arthur Accroc . Évalué à -3.
Debian piétine allègrement et sans raison valable le principe KISS à plusieurs endroits, à commencer par l’organisation même des dépôts.
Va-t-en maintenir sur disque amovible un miroir de la version courante pour mettre à jour une machine qui n’a pas d’accès à Internet rapide...
Debian, c’est une distribution faite par des coupeurs de cheveux en quatre pour des coupeurs de cheveux en quatre.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par Kerro . Évalué à 6.
Je fais ça sur un disque non amovible sans soucis. Qu'est ce qui est susceptible de poser problème ?
Depuis plusieurs années je n'ai eu que 4 ou 5 soucis avec la gestion des paquets. A chaque fois sur des machines pas à jour (comme celle que j'utilise actuellement qui est une Sid de 2008 bricolée à mort). Plus quelques gags genre installer des polices de caractères pour un utilitaire en ligne de commande. Je doute qu'aucune distribution ne soit à l'abris.
Ton commentaire s'applique peut-être à autre chose. Mais Debian est, malgré/grâce à son coupage de cheveux, une distribution très stable. Elle fait partie des distributions super pratiques pour des serveurs sans avoir à y passer des heures. Et elle fonctionne très bien pour les postes de travail.
Les BSD sont aussi des distributions de coupeurs de cheveux. Avec les avantages et inconvénients que l'on connaît. Sachant que les avantages sont disponibles pour tous (ssh, amélioration du code d'un peu tout le monde, etc) et les inconvénients disponibles uniquement pour ceux qui ont un BSD. Pareil pour Debian. Pareil pour Red Hat. Etc.
[^] # Re: Debian vs KISS
Posté par Arthur Accroc . Évalué à -5.
Pour une distribution « normale », il suffit de copier le répertoire de la version courante.
Sous Debian, les répertoires sont mélangés entre les versions et séparés par lettre, c’est inutilisable directement !
Alors il y a probablement une commande pour faire ça, mais c’est une complication inutile.
Les développeurs des *BSD sont des pinailleurs, mais il ne poursuivent pas le même but du tout : ils cherchent la qualité et la simplicité.
Sous Debian, une demi-douzaine de commandes pour gérer les paquets, ça ne ressemble plus à rien.
À condition de n’avoir aucun besoin particulier.
J’avais regardé à un moment pour un serveur web : Apache n’était pas compilé avec le support des bibliothèques dont j’avais besoin. Sur les autres distributions, si.
Sur une Debian stable, j’ai voulu installer un paquet d’un truc graphique de la testing, parce que j’en voulais une version récente.
apt-get a voulu une version plus récente de la Xlib, c’était raisonnable, j’essaye donc de la mettre à jour aussi.
Résultat : il me dit OK pas de problème, je vais désinstaller la majorité des applications graphiques...
À moins d’une très grande différence de versions, la Xlib a pour autant que je sache toujours conservé la compatibilité ascendante ; d’ailleurs, j’ai souvent utilisé sans problème des applications compilées par rapport à des versions de la Xlib plus anciennes que celle que j’avais sur mon système. Pour le mélange de paquets de différentes versions, je l’ai aussi fait sur d’autres distributions, et avec succès (même une fois une mise-à-jour de rpm et de la glibc pour des versions majeures plus récentes, autre chose que Xlib !).
Mais les empaqueteurs psychorigides de Debian ont décidé de mettre une dépendance stricte sur la version de la Xlib et pas juste une version minimale comme sur n’importe quelle autre distrib.
En fait, ça, c’était sur le conseil d’un sysadmin debianiste : « non, tu devrais quand même prendre la stable, tu configures les dépôts pour pouvoir prendre des paquets de la testing en le spécifiant » (une demi-journée ! mais il est vrai que je ne pouvais pas envisager de prendre les paquets à la main comme sur une distribution avec des dépôts normaux) « et tu pourras ajouter les quelques paquets plus récents dont tu as besoin, ça gère les dépendances, ça marche super-bien ». Bah voyons !
Bon, c’était un essai, j’ai encore une fois jeté la Debian. En fait, je n’en ai jamais mis en production.
Quand j’ai dû intervenir sur des Ubuntu (pas installées par moi), je suis tombé sur quelques autres trucs tordus (et pénibles) certainement hérités de Debian, mais quand même pas aussi calamiteux que le système de paquets.
Je crois que je préférerais encore devoir administrer une Slackware (pas de gestion des dépendances) qu’une Debian.
Suggestion : jetez tout le système de paquets, passez à pacman.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Si tu n'aimes pas avoir le choix, il y'a Mac App Store de Apple.
Et oui, à un moment des choix sont fais et c'est ainsi partout. Si je veux ZFS, je prend pas Linux. Après tu as plusieurs méthodes pour arriver au résultat voulu, prendre une autre distribution est un choix, compiler Apache pour ton besoin est un autre.
C'est l'essence même de de Debian. Tu prends la stable et tu sais que tu n'as pas de changement en terme de comportement durant toute la durée de vie. Si tu veux faire du mélange, tu peux, mais c'est de l'utilisation avancée et tu dois t'attendre à prendre des risques et casser ton système.
D'ailleurs la stable, la testing et la unstable sont considérées comme trois distributions majeures par le projet Debian. Mélanger deux, revient à mélanger Gentoo et Redhat, par exemple.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Altor . Évalué à 2.
De suite les gros mots. Il y a une différence entre avoir le choix et compliquer inutilement une opération qui devrait être simple.
N'ayant jamais fait ça sous une distribution gérant les dépendances, ça se passe comment lors d'une mise à jour ? J'imagine que tu interdits la mise à jour du paquet modifié, mais qu'est-ce qui se passe pour les paquets qui dépendent de celui-ci ?
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
aptitude install equivs
man equivs-control
man equivs-build
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Altor . Évalué à 1.
Ok, alors si j'ai bien compris, voilà ce qu'il faut faire :
- on part d'un paquet A.deb que l'on recompile (pour ajouter une dépendance au ./configure par exemple).
- on crée un paquet A-moi.deb
- on fait la mise à jour de A.deb avec A-moi.deb
- on crée un paquet vide appelé A.deb comme ça, pour B.deb qui dépend de A.deb A est toujours là.
Maintenant, ma question, si je dois mettre à jour qu'est-ce qui se passe ? A.deb (le faux) devient A+1.deb (un vrai paquet) ? A-moi.deb reste ? Disparait ? Ou alors il faut nettoyer à la main le système ?
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Si tu modifies un paquet c'est plus simple. Tu utilises les outils Debian pour obtenir le paquet source, tu modifies le paquet source (patch, modification des options de compilation), tu ajoutes ton numéro de version (genre +0.local.1 au numéro actuel) et tu utilises les outils Debian pour reconstruire le paquet et l'installer proprement. Ton paquet ne sera pas mis à jour automatiquement, c'est à toi de le gérer. Par contre si tu ton paquet est 1.2-0+0.local.1 et que Debian fourni 1.3-0, aptitude va vouloir le mettre à jour (mais ce changement ne devrait pas se produire durant la durée de vie d'une stable).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Arthur Accroc . Évalué à 1.
Enfin une solution humaine ! C’est ce que je fais avec d’autres distributions quand j’ai besoin de modifier un paquet (sauf que je me contente de lftp pour charger le paquet source).
En fait, quand j’ai testé la Debian, j’ai voulu tenter de faire les choses façon Debian et j’ai donc demandé conseil au debianiste du coin. C’était sûrement là l’erreur.
Pour éviter ce risque, je trafique le numéro de version en y ajoutant un nombre assez important et rond ; ça ferait par exemple 1.1002-0. Comme ça, pas de mise à jour intempestive, mais on voit quand même que ça a été trafiqué et on peut deviner la version d’origine.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
C'est la façon Debian de faire. Il y'a un excellent (fr) livre écrit par dev Debian : "Debian, Administration et configuration avancée" chez Eyrolles (ISBN: 2-212-11904-6) où tu trouveras tout ça et même plus.
Ça c'est déjà une moins bonne idée et ça n'apporte rien sinon des soucis. Parce que dans la stable le numéro ne va pas changer (normalement) et si tu es sur testing ou unstable, tu peux étiqueter la version de ton paquet dans
/etc/apt/preferences:"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Enoch (site web personnel) . Évalué à 3.
Une autre solution pour empêcher la mise intempestive du paquet :
Cette option sert justement à marquer un parquet pour indiquer à apt et aptitude de ne pas le mettre à jour automatiquement.
[^] # Re: Debian vs KISS
Posté par Arthur Accroc . Évalué à 1.
De quel genre, à part une éventuelle dépendance d’un autre paquet à la toute dernière version ?
Ce que ça apporte par rapport à une exclusion du paquet (il n’y a pas que sous Debian que c’est possible), c’est qu’en cas de mise à jour du paquet d’origine, je refais le mien, je le mets dans le dépôt local et les machines le prennent à leur mise à jour suivante. Pas besoin de commande spécifique, simple (KISS, quoi).
Après, je maintiens aussi une liste d’exclusion centralisée pour des paquets qui causeraient problème (quelquefois un paquet du dépôt contrib cause un conflit avec un autre, alors que son ancienne version passait).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Si quelqu'un reprend derrière toi, il risque de pas comprendre et il va être énervé (et s'il est plus costaud que toi, il risque de te démonter la tête à grand coups de latte). En plus je trouve ça pas propre.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Arthur Accroc . Évalué à 2.
Si quelqu’un reprend derrière moi, il trouvera ce paquet dans le dépôt local avec les quelques paquets complètement spécifiques (c’est un dépôt séparé des copies locales des dépôts officiel), à maintenir aussi.
Si quelqu’un reprend derrière moi, soit je serai là sur une autre tâche et je l’aiderai à se repérer... soit je serai loin ! ;-)
Bon, en fait, j’ai déjà un collègue au courant de l’organisation générale du truc.
Oui, mais tu es un debianiste, c’est ta tendance naturelle à pinailler. ;-)
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par barmic . Évalué à 2.
La modification du préférence te permet d'autoriser les mises à jour venant de ton dépôt et pas des dépôts officiels.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian vs KISS
Posté par barmic . Évalué à 2.
Avec lftp il faut le faire pointer vers un dépôt là où apt-get source zsh va te télécharger le paquet depuis tes dépôts avec les sources mainstream et toutes les modifications faites par Debian séparées.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian vs KISS
Posté par Arthur Accroc . Évalué à 0.
J’aime avoir le choix. Par exemple, le choix d’un paquet Apache compilé avec toutes les options, le choix de pouvoir essayer un paquet plus récent...
Là, ce n’est pas le choix des commandes, c’est le choix des effets de bord (encore faut-il en être conscient !). C’est de la complexité, pas un choix utile.
Pour la gestion des paquets, j’aime mieux avoir une seule commande ou un ensemble de commandes cohérent pour les opérations de base (genre pacman) ; il est toujours temps de proposer un choix sur les frontends.
Oui, mais pas aux bons endroits : dommage que ce ne soit pas sur la gestion des paquets...
Encore un mauvais conseil d’un debianiste : faire le choix de compiler, ce n’est pas anodin, ça implique de recompiler à chaque mise à jour de sécurité.
Ça m’est arrivé pour des besoins très spécifiques, mais dans les cas courants, c’est à éviter. Ou alors, il faut prendre une Gentoo (on compile, mais les mises-à-jour sont gérées).
Même les bugs très gênants restent (parce qu’autrement, ce serait dommage) : par exemple, une version d’IceWM avec un bug très gênant sur le placement des fenêtres (la seule à l’avoir parmi des tas de versions plus anciennes ou plus récentes que j’ai utilisées) est bien restée.
Il y en a qui le conseillent (vu le résultat, c’est idiot).
Il y a des tutoriaux pour ça (pareil).
Pour le truc que j’ai essayé, ça ne casserait pas le système, et au pire, j’aurais pris le risque.
Mais les empaqueteurs empêchent de le faire ; c’est la seule distribution (au moins dans celles que j’ai utilisées et sans compter les dérivées de Debian) où les paquets contiennent des dépendances strictes là où des versions minimales conviendraient.
Sur les autres distributions, on peut au moins essayer ; là encore, pas le choix justement.
Enfin au moins, c’est bien assorti avec Gnome...
Mauvaise foi, l’architecture de la distribution reste la même. Ça reviendrait à mélanger une CentOS 5 avec une 6 (je prends l’exemple d’une distribution qui ne sort pas plus fréquemment). Et si un debianiste me demandait conseil à ce propos, je lui conseillerais d’éviter si possible et en tout cas d’essayer de recompiler les paquets pour limiter les dépendances (sauf peut-être au crétin qui m’avait donné le mauvais conseil pour la Debian).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Ce qui est le cas. Le gestionnaire de paquet est dpkg, les autres ne sont que des interfaces de haut-niveau. En passant par dpkg, tu peux télécharger un .deb et l'installer en ignorant les dépendances. Il suffit de lire la man page de dpkg.
dpkg = pacman
Après, avec aptitude ou apt, tu peux faire des mélanges, mais ça demande un peu plus de connaissances que trois options sur une ligne de commande.
Je ne pense pas que tu parlais des cas courant pour ta librairie particulière qu'uniquement Debian ne possédait pas. Après pour l'histoire de Xlib je suppose que ce n'était pas sur un serveur en production.
dpkg --force-all -i paquet.deb
Pas vraiment. Le format de paquet est le même, l'architecture pas forcément. Généralement ça l'est.
Je crois qu'il s'agit plus d'une méconnaissance de Debian que de choix imposer par Debian. Debian, et c'est ce que j'aime, ne se met pas en travers du chemin si tu essaies de faire des subtilités non prévues et fournis même des outils pour aider (si tu veux les utiliser), par exemple si tu veux compiler ton propre paquet qui va remplacer un paquet nécessaire à Debian, tu peux utiliser equivs pour ça.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Arthur Accroc . Évalué à 1.
Je sais lire les man et j’ai déjà utilisé dpkg.
Le problème est dans « télécharger ». Quand il faut trouver un paquet dans le foutoir d’un dépôt Debian, c’est un peu plus compliqué que sur une autre distribution. Quand il y a aussi un certain nombre de dépendances qu’il faut trouver dans la bonne version, c’est juste la merde (à moins qu’ils ne se soient enfin décidés à ranger les paquets par version de la distribution ; si c’est le cas, je serai content de l’apprendre).
Non, pacman fait aussi le boulot d’apt-get voire d’autres commandes (voir ici).
Je sais bien, c’est pour ça que ça m’a pris pas mal de temps pour mettre ça à peu près au point. Tout ça pour me faire avoir par les dépendances strictes sur les paquets...
Non, mais après tout ça n’aurait pas été un gros soucis : les outils d’administration graphiques peuvent éventuellement être impactés par un tel changement, mais pas les services.
Au delà, en maintenant un serveur dont la distribution n’avait plus de mises à jour, j’avais fini avec un noyau vanilla beaucoup plus récent compilé à la main, des paquets binaires des deux versions suivantes (dont la glibc) et des paquets de celle d’après recompilés. Finalement, le système était plus stable qu’au départ (pas très dur : le noyau d’origine était un des premiers 2.4, avec une version de NFS franchement boguée) et même plus stable que la distribution que j’ai installée après (jusqu’à ce que j’aie aussi repéré et pris en compte les bugs des logiciels qui la composent).
Debian fait des trucs complexes et éventuellement d’autres trucs complexes (qu’il faut trouver) pour permettre de contourner les premiers si on a des besoins particuliers. Ce n’est pas ce que j’appelle ne pas se mettre en travers du chemin.
La distribution qui ne se met vraiment pas en travers du chemin, c’est Slackware : elle fait juste le minimum et après, tu te démerdes « à la main », comme sur n’importe quel Unix.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
aptitude download paquet
C'est un choix. Là c'est un outil qui s'occupe d'installer/supprimer les paquets et un outil qui s'occupe d'obtenir les paquets.
Debian ne fait rien à moins que tu lui demande de faire quelque chose. Tu peux entièrement administrer ton système à coups d'aptitude download et dpkg -i, c'est à toi de décider ce que tu veux. Par contre c'est très puissant, mais ça reste très progressif. Tu peux partir de débutant et finir maître, en utilisant Debian, et avoir remplacé toutes les briques du système pour faire tourner GNU/Hurd (ah, on me dit que c'est déjà fait).
Perso j'utilise/ai utilisé plein de distribution. Pour toi, tu fais ce que tu veux ça me change pas le prix de la bière. Par contre il est bien de savoir ce qu'il est possible de faire avec une distribution. La première fois que j'ai utilisé Debian, j'ai jeté après une semaine en disant comme toi ...
Par contre je pensais testé Slackware pour me faire un Dom0 Linux 3.0 en ayant la distribution m'installant le stricte nécessaire et "disparaître" ... un genre LFS mais l'installation automatique (ALFS m'attire pas vraiment), je sais pas si ça fonctionnerait bien ça ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Altor . Évalué à 1.
Slackware fonctionne aujourd'hui comme une base sur laquelle on peut construire ce que l'on veut.
Voilà de la doc pour réaliser le dom0 :
- ici le slackbuild (script pour compiler et créer des paquets pour slackware) de xen.
- pour le dom0
Pour utiliser Linux 3.0 il semblerait qu'il y ait quelques problèmes avec uname mais je ne sais pas si c'est spécifique à Slackware
Bonne chance
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Je penses pas mais Debian testing a commencé à intégrer Linux 3.0, je pourrais aller piocher là-dedans.
Merci.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Arthur Accroc . Évalué à 1.
Merci, j’avais loupé cette option (je n’en ai jamais eu besoin sur une autre distribution et je n’y ai tout simplement pas pensé). Ça pourra me servir (au moins quand j’interviens sur des Ubuntu).
Après, j’ai déjà été confronté à un cas où ça n’aurait pas résolu pas le problème : un dépôt tiers dont les commandes apt* avaient estimé que le fichier descriptif était défectueux. C’était sûrement vrai, mais du coup, au revoir apt*, retour au téléchargement à la main en essayant de deviner quelle version pouvait bien correspondre à la distribution...
Je reste donc convaincu que séparer les paquets par version de la distribution est un bon principe (simple, pratique).
Pour les dépendances strictes plutôt qu’à une version minimale, ça ne résoud pas non plus. Il faut modifier et recompiler le paquet source.
Un choix qui a des avantages : à ce que j’ai vu, aussi bien dans le monde Debian que dans le monde rpm, les commandes de haut niveau court-circuitent la commande de base (dpkg ou rpm) pour plus d’efficacité et éventuellement maintiennent une base supplémentaire.
Du coup, utiliser une commande de haut niveau ou de base n’assure pas d’un résultat parfaitement identique. Avec une seule commande, aucun soucis.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Debian vs KISS
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Non, apt et aptitude utilisent dpkg via libapt-pkg
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Debian vs KISS
Posté par Donk . Évalué à 3.
Pour ça il y a le site http://packages.debian.org/
# la commande MAN
Posté par YannPeniguel . Évalué à 2.
http://man.cx/aptitude%288%29
idem pour les autres outils suscités.
La commande man est un outil merveilleux.
Pour chaque personne qui me plussoie, je frappe un fan de Justin Bieber.
[^] # Re: la commande MAN
Posté par BAud (site web personnel) . Évalué à 10.
dans le cadre des lois de parité, une commande woman a été demandée, à des fins d'équité :-)
[^] # Re: la commande MAN
Posté par zebra3 . Évalué à 10.
C'est quoi ces histoires de cheval ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: la commande MAN
Posté par BAud (site web personnel) . Évalué à 7.
OMG poneys !1!1!11111!!!! /o\
[^] # Re: la commande MAN
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
D'autant que fournir un manuel pour chaque commande est obligatoire, selon la charte Debian.
[^] # Re: la commande MAN
Posté par coïn . Évalué à -6.
très peu sont de qualité
[^] # Re: la commande MAN
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Dans ce cas, le mieux à faire est de signaler ces manques en faisant des rapports de bogue, niveau de gravité serious. Ces rapports devraient être traités assez rapidement par les mainteneurs correspondants étant donnés qu'ils sont bloquants pour l'admission ou le maintien d'un paquet dans Debian. Autrement dit, avec un bug sérieux, un paquet ne rentrera pas dans la prochaine Debian stable.
Évidemment, les correctifs sont les bienvenus. Un rapport de bogue, c'est bien, un rapport de bogue avec correctif, c'est mieux.
[^] # Re: la commande MAN
Posté par Maclag . Évalué à 3.
Mouai, attention à ne pas soulever un nouveau bogue de gravité "serious" pour tout et n'importe quoi.
Pour une documentation "mal" écrite, il est délicat de dire si le bogue est grave ou pas, c'est très subjectif!
Le mainteneur aurait vite fait de descendre le bug de quelques niveaux, juste parce que recevoir un bug "serious" expliquant en gros que "ta doc c'est de la merde!", ça ne part pas super bien côté diplomatique...
[^] # Re: la commande MAN
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ne pas documenter une commande, c'est une violation de la charte Debian, et ça implique un bogue de gravité serious.
[^] # Re: la commande MAN
Posté par Maclag . Évalué à 4.
Oui, je sais et je suis bien d'accord.
Je dis juste qu'il faut faire attention à la différence entre "non documenté" et "mal documenté".
Dans le deuxième cas, il est pertinent de soulever un bug pour faire comprendre au mainteneur que la doc va de "difficilement utilisable" à "complètement inutilisable mais a le mérite d'exister...".
Une doc existante mais catastrophique mérite un bug serious. Une doc existante mais pas très claire peut être une raison de soulever un bug moins haut dans la liste des priorités.
Enfin, une doc pour laquelle le commentaire c'est "pas assez d'exemples", je serais presque tenté d'envoyer le bug en wishlist!
[^] # Re: la commande MAN
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Très peu, je ne sais pas. Certains sont de mauvaise qualité en effet. Mais par ailleurs, d'autres sont non seulement de bonne qualité, mais ont été adopté par le projet amont. Debian est un moteur de documentation.
# Ca veut dire...
Posté par pasBill pasGates . Évalué à 9.
qu'ont peut enfin mettre des paquets (classes) X dans la distrib ?
[^] # Re: Ca veut dire...
Posté par Tonton Th (Mastodon) . Évalué à 10.
hotbabe \o/
[^] # Re: Ca veut dire...
Posté par Juke (site web personnel) . Évalué à 4.
ou weboob http://lists.debian.org/debian-mentors/2011/04/msg00111.html
# c'est aussi la seule distirbution a ne pas integrer gnome
Posté par modr123 . Évalué à 10.
ce qui est un choix plutot judicieux vu comme gnome est moche et peu ergonomique
[^] # Re: c'est aussi la seule distirbution a ne pas integrer gnome
Posté par Nerdiland de Fesseps . Évalué à 2.
C'est surtout que Gnome est trop complexe à maintenir pour leur équipe restreinte. Depuis que KDE est passé à un nouveau système de packaging plus complexe, ils parlent de le virer aussi. Comme ça, pas de jaloux.
# La mère de tous les vices
Posté par Michaël (site web personnel) . Évalué à 5.
Les feignants qui font semblant de travailler?
[^] # Re: La mère de tous les vices
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
En effet, ça devrait plutôt être « fainéant », anciennement écrit « faitnéant » : quelqu'un qui ne fait rien. J'ai découvert cette étymologie en lisant le Gargantua en texte original, à l'époque ça s'écrivait ainsi.
[^] # Re: La mère de tous les vices
Posté par Dr BG . Évalué à 5.
Ce n'est pas l'avis de l'Académie française :
Je regarderai ce qu'en dit mon dictionnaire historique de la langue française ce soir.
[^] # Re: La mère de tous les vices
Posté par Dr BG . Évalué à 3.
Bon, le dictionnaire historique de la langue française dit la même chose : fainénant est une altération de feignant.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.