Bonjour,
après avoir bien regardé ce que proposait Gentoo et éliminé toutes FC2, Mandrake 10 ou Debian-like après les réponses de fifre, Vincent P et Pascal à mon post tgz vs packages, j'hésite profondément entre :
Slackware et Gentoo.
Tout me plait chez les 2 distribs (sûres, claires, concises).
Par contre :
Ce qui reste flou pour la Gentoo : même si on compile tout, cela reste basé sur des packages. Donc, si on désire installer l'appli Griboubichloup_0.2.6a2 qui ne possède pas d'ebuild, qu'est-ce qu'on fait ? On ./configure && make && make install et ça peut poser problème ?
Ce que reste flou pour la slackware : les packages, ça a aussi du bon. Si je compile les sources d'une appli Y qui nécessite absolument l'appli X, est-ce que la désinstallation de Y entraînera celle de X ? Si je souhaite virer Y, puis savoir qui quelqu'un l'utilise avant de faire une boulette. Bref, y'a-t-il une gestion des dépendances ? Il me reste qq mauvais souvenir de slackware :)
J'espère que je ne pose pas de questions trop couillonnes...
Merci.
Forum Linux.débutant Choix final : Slackware ou Gentoo ?
29
juil.
2004
# Sous gentoo..
Posté par Superted . Évalué à 2.
De toute façon le nombre de paquets gentoo est très important, et je n'ai que quelques applis installées à la main.
Pour slackware tu te demandes :
Si je souhaite virer Y, puis savoir qui quelqu'un l'utilise avant de faire une boulette
Je ne connais pas slackware, mais tu dois savoir que ce problème existe également sous gentoo ! En effet, il n'y a pas de gestion des dépendance "inverse". En fait si tu installes un paquet A qui demande la présence du paquet B, alors le paquet B est installé automatiquement. Mais si tu désinstalles le paquet A, B restera installé, alors qu'il n'est plus utilisé.
A vrai dire c'est LE gros reproche que l'on peut faire à portage qui par ailleur est de très bonne qualité, et possède de très bonnes fonctionnalités.
[^] # Re: Sous gentoo..
Posté par oudoubah . Évalué à 1.
Le problème sité par Superted doit exister sur toutes les distribs amha.
Quelque soit la distrib, tu peux toujours installer des applis à la main avec un ./configure && make && make install.
[^] # Re: Sous gentoo..
Posté par tgl . Évalué à 4.
> en faisant un ./configure && make && make install.
Perso je n'installe jamais rien de cette façon. Quand j'ai besoin d'une appli qui n'est pas dans portage, je me fait rapidos un ebuild bien baclé, ça prend 5 minutes et puis voilà, mon soft est installé proprement (donc désinstallable, etc.). Et puis comme ça au passage, si je me dis que ça peut intérresser des gens, alors je fignole un peu plus et je balance ça sur le bugzilla.
L'apprentissage de l'écriture d'ebuild est relativement simple, et c'est vraiment un bon investissement. La doc est bien faite, et puis y'a queqlues milliers d'exemples dans l'arbre portage pour trouver l'inspiration. Bon maintenant, il y a bien sûr des ebuilds compliqués à écrire, c'est clair, mais c'est typiquement pour les soft ou le "./configure ; make ; make install" aurait soit été insuffisant, soit ferait tellement d'autres choses que de coller qlqs fichiers dans /usr/local qu'il aurait vraiment été à proscrire pour garder son système propre.
> En fait si tu installes un paquet A qui demande la présence du paquet B,
> alors le paquet B est installé automatiquement. Mais si tu désinstalles
> le paquet A, B restera installé, alors qu'il n'est plus utilisé.
Ça c'est rien, "emerge -p depclean" de temps en temps et c'est nettoyé. Pour ceux qui connaissent pas, le principe est de virer tous les paquets installés qui ne sont pas référencés dans les groupes "system" ou "world", ou dans les dépendances directes ou indirectes des paquets de ces groupes. Le groupe "system" étant une liste des paquets de base indispensables spécifiés par les développeurs gentoo, et le groupe "world" la liste des paquets que l'utilisateur a explicitement installés (par explicitement, j'entend que si on fait "emerge MegaPlop", seul MegaPlop est ajouté au world, mais pas les éventuels autres paquets, par exemple des bibliothèques, dont il dépend).
[^] # Re: Sous gentoo..
Posté par Alexandre Dombrat . Évalué à 1.
C'est quoi un ebuild ? C'est spécifique à une distrib ou commun aux linuxes ?
En fait, tu fais un package genre .deb ?
J'ai vaguement vu qu'il y avait un make-kpkg ou une commande du genre, ce qui construit je crois un .deb à partir d'une tripotée de règles pour définir le package (dépendances, suggérés, recommandés, conflits...). En somme, c'est un peu ça que tu utilises ?
(désolé pour la question con, mais sorti de debian, je connais plus grand chose...)
[^] # Re: Sous gentoo..
Posté par tgl . Évalué à 2.
> commun aux linuxes ?
C'est spécifique à Gentoo.
> J'ai vaguement vu qu'il y avait un make-kpkg
Si mes souvenirs de debianeux ne sont pas trop rouillés, ça c'est pour faire un paquet pour un noyau et ses modules. C'est un cas un peu particulier.
> ou une commande du genre, ce qui construit je crois un .deb
> à partir d'une tripotée de règles pour définir le package (dépendances,
> suggérés, recommandés, conflits...). En somme, c'est un peu ça que tu
> utilises ?
Voilà oui, enfin l'équivalent gentoo. Perso je le trouve bien plus simple : un ebuild est un simple fichier bash, et une fois qu'il est prêt tu n'as plus qu'à faire ton "emerge <nom-du-logiciel>". En fait, sous Gentoo, tout est installé de cette manière, à partir d'une collection standard d'ebuild ("l'arbre portage"). Le fait d'avoir tout ça sous la main (alors que sous debian l'utilisateur de base n'est pas en contact avec les specifications de paquets) fournit plein d'exemples et rend plus naturel le fait de rajouter ses propres paquets.
Sous debian, je trouve la création des fichiers de specification plus fastidieuse, et une fois que c'est fait il reste des étapes intermédiaires avant d'arriver à qlqchose qui est exactement équivalent à un paquet standard. Du coup, quand j'étais debianeux, c'était assez rare que je prenne la peine de passer par là et j'avais plus tendance à faire des "configure ; make ; make install" hors du système de paquets. Sous gentoo je ne le fais plus du tout, et je sais que je suis loin d'être le seul à avoir ainsi changé mes habitudes.
# Façile
Posté par jerome (site web personnel) . Évalué à 1.
Tu peux gérer facilement avec un chroot voir avec des méthodes un peu plus complexes.
La gestion des dépendances sur lors de la désinstallation de paquets n'est pas l'argument de vente de ces distros. En fait, si, ya un argument, tu les gères toi même et ça doit être bien parce que c'est ce que tu veux.
Finalement pour les paquets ... Ben un ebuild, c'est pas dur à faire, c'est juste un court script python. Et quand bien même tu devrais configurer/compiler/installer toi même, ça ne veut pas dire que tu sois obliger de le faire salement ...
Pour t'aider, utilise des outils comme stow, garde tes sources comme tu le fais pour ton noyau dans un endroit qui va bien (/usr/local/src ?), pi voilà.
# Pour ce qui concerne la Slackware
Posté par Ellendhel (site web personnel) . Évalué à 1.
Pour ce qui est de la Slack : Si je compile les sources d'une appli Y qui nécessite absolument l'appli X, est-ce que la désinstallation de Y entraînera celle de X ? je dirais non vu qu'il n'y a rien qui le lie de maniere reciproque (personellement je ne desinstalle rien, je laisse moisir dans un coin).
Si je souhaite virer Y, puis savoir qui quelqu'un l'utilise avant de faire une boulette non a priori non plus, pas de garde-fou.
Bref, y'a-t-il une gestion des dépendances ? Non. Du moins de tres pousse, encore que depuis la presence de l'outil swaret il y a quelque chose d'equivalent (pareil, je ne l'utilise pas, je joue rarement avec les installations / desinstallations).
Si tu as un peu de temps, tu peux voir sur http://slack-fr.org/(...) et sur le canal irc dedie (les forums sont encore a l'etat de fantomes).
[^] # Re: Pour ce qui concerne la Slackware
Posté par TalvinS . Évalué à 1.
Le choix étant trop difficile, je pense que je vais effectivement installer les 2. Une sur mon portable K6-??? (slackware je pense) et une sur mon fixe Athlon-XP.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.