Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe
Hors ligne
TUTO EN COURS DE COMPOSITION.
VERSIONS PROPOSÉES :
======= SOURCES.LIST (Version 1) =======
Ici, les branches Debian sont nommées uniquement par leurs noms communs à savoir **Stable**, **Testing** et **Unstable**.
Il vous revient donc à chacun de transcrire
les nom de code release là où il y a lieu les amis !
===== Débutants =====
Consultez ces liens des explications détaillées pour les branches et les dépôts debian avant de poursuivre...
Là : [[manuel:branches_debian | Les branches Debian - Détail]] (stable- testing - unstable - expérimental...)
Et là : [[manuel:depots | Le Manuel des Dépôts Debian]]. Explication sur les dépôts debian à installer.
//Histoire de pas mettre la charrue avant les boeufs quoi...//
===== Le fichier /etc/apt/sources.list =====
Contient la liste des dépôts qui vous permet de mettre à jour votre système et d'installer de nouvelles applications ou d'autres paquets utiles à son fonctionnement.
Lorsqu'on ajoute des dépôts à ce fichier sources.list, comme nous le verrons plus loin, il devient vite important de __créer un fichier__ ///etc/apt///**preferences** afin de pouvoir gérer correctement ces dépôts.
===== Les sources.list - A savoir : =====
La version stable de debian a l'avantage d'être une distribution robuste pour les serveurs web.
Mais en tant que **desktop** elle peut vite montrer ses limites pour qui voudrait installer les dernières versions de tels ou tels logiciels.
=== Note : ===
Nous avons opté dans les exemples de fichier sources.list présentés ci-après
de commenter la ligne des sources de sécurity afin de l'inactiver.
===== Les fichiers sources.list Debian - En détail : =====
* [[manuel:stable_cd_dvd | Les sources.list Stable par CD ou DVD en détail]]. La branche stable CD et DVD - Détail
* [[manuel:stable_détail | Les sources.list Stable en détail]]. La branche stable Le commencement - Détail
* [[manuel:testing_détail | Les sources.list Testing en détail]]. La branche testing - Détail
* [[manuel:unstable_détail | Les sources.list Unstable en détail]]. La branche unstable - Détail
* [[manuel:experimental_détail | Les sources.list Experimental en détail]]. La branche experimental - Détail
===== Nom de code des "release" debian =====
**release** se traduit par : "**sortie**" en français.
Avouons que **sortie** est bien moins parlant, et, faute de mieux, en harmonie avec les Développeurs Debian, nous garderons cette terminologie anglaise **release** pour désigner les noms de code particuliers attachés à chaque branche finalisée.
Ces nom de code particulier des branches finalisées permettent de :
- les utiliser //nommément// avec les matériels adaptés à leur construction.
- maintenir la pérénité des installation pour tous les matériels installables en les associants avec ces branches **releases**, branches hors du cycle de test et de configurations.
Chaque branche **release** porte en nom de code l'un des noms des personnages du film d'animation **Toy Story**.
lenny - squeeze (actuellement...)
* **lenny** désignera toujours la même branche,
* **squeeze** également la sienne en devenant //stable//, puis //oldstable// à son heure...
Il est une troisième branche dont le contenu est perpétuellement en mouvement, la //unstable//, cette branche a pour nom de code //release// : sid !
Cette branche sid n'a pas de contenu définitif en place à ce stade.
On dit qu'elle est //cassable// ! hi hi hi...
Aussi, à la prochaine évolution, elle prendra un nouveau nom de code en passant à //testing// avec un nom **release** définitif tandis que la branche venue de //experimental// prendra sa place d'//unstable// sous le nom de code : **sid** à son tour,
Le temps de sa composition en construction...
C'est le cycle adopté par les //Développeurs Debian// afin de maintenir toute la cohérence **légendaire** du système **GNU/Linux-Debian**, ici chéri... Yop !
===== Le nom commun des branches debian =====
A contrario, celui des noms communs stable - testing...
suivent eux les évolutions des branches Debian
(la branche testing précédente (nommé avec un nom qui la définie comme **release**) devient la branche stable (en conservant son nom de **release**) dans son évolution et ainsi de suite...
==== Dans le fichier /etc/apt/sources.list, ====
Vous pouvez utiliser :
les noms de baptême pour identifier les différentes branches (lenny -squeeze - sid),
ou bien :
les noms communs (stable - testing...).
==== Utiliser les noms communs des branches ou leurs noms de code releases... ====
<note importante>ATTENTION !</note>
Si vous utilisez les noms communs des branches debian (stable, testing...) dans votre fichier **/etc/apt/sources.list**
vous devrez faire attention lorsqu'une nouvelle branche évoluera et passera de testing à stable !
En effet, avec le **nom commun** (stable, testing...),
vous passez immédiatement de la branche stable ancienne à la nouvelle branche venue de testing !
Il faut dire que dans les premiers jours des évolutions des branches, certaines imperfections peuvent survenir...
=== Pour s'en préserver : ===
En utilisant le nom de code des //release// **lenny**, **squeeze** et **sid** votre branche habituelle est préservée et vous pourrez ainsi choisir l'instant de votre mise à jour
quand vous le désirerez
et non de manière automatique !
Ne soyez pas timides les enfants ...
Tchibâââ !
Amitié, Joel
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par smolski (27-08-2009 13:29:31)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe
Hors ligne
je pense qu'il est préférable de mettre l'accent sur Lenny
Réponse de Jojo :
Très bon point de vue et qui m'enchante !
mani a dit :
Le lien que tu as mis propose une mise en forme qui n'est à mon avis pas adaptable avec notre documentation
Pardon, je n'ai pas été assez clair...
Je n'utilise ce lien que pour le cadre de ce tuto particulier de la Gestion des Dépôts rassemblant des fichiers et des informations complémentaires et multiples... Très... mulitples !
Je propose seulement de ne pas mettre en vrac tous ces aspects, nécessaires mais volumineux !
Mani a dit :
de mettre temporairement de côté ce débat et d'en ouvrir un plus général sur l'organisation et la hiérarchisation de l'information au sein de notre wiki
Not' wiki est le plus bô des wiki DF possible dans sa hiérarchisation actuelle. Non ? Pas de débat à mon sens là-dessus.
Encore une fois, c'est le particularisme du sujet traité qui me fait envier une certaine douceur et légèreté, tel qu'il est présenté dans le lien exemple.
Sur ce, joel propose :
Garder l'idée du tuto que tu présentes, net clair, bon à copier / coller mais en utilisant carrément le nom de code release de la branche actuellement stable, juste à le changer ensuite lors des prochaines évolutions, en le signifiant tel.
C'est à dire :
sources.list type pour débutant : Branche Lenny.
et, par ailleurs, lancer les sources.list type très raccourcis en les appelants :
Sources.list type pour débianeux confirmé ou amateur curieux...
Et y mettre les testing et sid seuls
Et mettre tous les sources.list dans le sens que je propose... très courts et des liens en notes diverses, plutôt que les notes elles-mêmes.
Suivre ensuite avec le preferences et le pinning séparément, comme je le propose initialement.
Je pense que le débutant, trouvant dans le premier la majeure partie des réponse à ses premières intérrogations pratiques, pourrait suivre à son rythme sur les sources.list plus élaborés de la suite...
Il faut préciser que martin a signalé qu'il était aussi bienvenue de préserver certains puristes désirant consulter et préconiser une version stable ni contrib, ni non-free... ce qui fut mon soucis dans le premier tuto sources stable proposé...
Ce est-ce bon comme idée ?
Amitié, Joel
Dernière modification par smolski (27-08-2009 17:03:49)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Pardon, je n'ai pas été assez clair... [...] Encore une fois, c'est le particularisme du sujet traité qui me fait envier une certaine douceur et légèreté, tel qu'il est présenté dans le lien exemple.
Merci de tes éclaircissements qui dissipent mes interrogations, j'avais effectivement mal compris ton point de vue !
Garder l'idée du tuto que tu présentes, net clair, bon à copier / coller mais en utilisant carrément le nom de code release de la branche actuellement stable, juste à le changer ensuite lors des prochaines évolutions, en le signifiant tel.
Oui j'y pensais aussi, ça évite les migrations forcées à la sortie d'une nouvelle stable en plus.
C'est à dire :
sources.list type pour débutant : Branche Lenny.
et, par ailleurs, lancer les sources.list type très raccourcis en les appelants :
Sources.list type pour débianeux confirmé ou amateur curieux...
Et y mettre les testing et sid seuls
Ça me va !
Et mettre tous les sources.list dans le sens que je propose... très courts et des liens en notes diverses, plutôt que les notes elles-mêmes.
Si j'ai bien tout compris, tu veux dire mettre des liens dans le fil du texte sur Lenny qui renverraient vers les différents sources.list ? Tout en laissant le sources.list complet dans le corps même de cette page ? Par exemple, en reprenant la hériachie de ce que j'ai écrit :
Oui pourquoi pas, même si je ne te cache pas qu'il me reste un doute sur l'utilité de prendre autant les lecteurs par la main. Ceci dit j'avoue avoir du mal à me mettre dans la peau d'un débutant pour juger précisément des infos primordiales. 
Suivre ensuite avec le preferences et le pinning séparément, comme je le propose initialement.
Tout à fait, avec beaucoup plus de détails que sur la page consacrée à la configuration en deux coups de cuillière à pot de Lenny ! On peut y rajouter le fichier apt.conf aussi d'ailleurs.
Il faut préciser que martin a signalé qu'il était aussi bienvenue de préserver certains puristes désirant consulter et préconiser une version stable ni contrib, ni non-free... ce qui fut mon soucis dans le premier tuto sources stable proposé...
Remarque prise en compte dans mes propositions de sources.list alternatifs...
« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe
Hors ligne
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
tu veux dire mettre des liens dans le fil du texte sur Lenny
Pas sur le sources.list Lenny type des débutants que tu proposes, seulement pour les autres sources.list et sous les noms communs de branche stable - testing - unstable, présentés comme destinés à plus aguerris et que nous n'auront pas à reprendre sur ce point lors des évolutions... Contrairement au tien où nous réactualiserons le nom de code release de la branche stable.
Ton texte explicatif en soit me paraît tout à fait adapté et se suffit en lui-même.
Et :
il me reste un doute sur l'utilité de prendre autant les lecteurs par la main.
En fait, c'est de proposer une suite pour "débutants qui voudraient s'aguerrir" à qui cette série de sources.list (relativement brut et avec les liens pour rappel...) s'adresse prioritairement...
Ainsi que pour des explications brèves dans le forum ou le chan...
Bien sûr, conserver le fichier apt.conf en exergue comme les dépôts, et fichiers preferences et pinning. Ton exemple de liens sous code est très bon en ce sens... J'y rajouterai le sources.list des testing et unstable utilisables avec une note brève quant à leur stabilité érratique !
Merci martin pour ton avis et tes renseignements si détaillés et précieux...
Enfin, cette opération stratégique pour le wiki des sources.list et consorts a été appelée par des questions redondantes sur ce forum où il appert que les débutants ne lisent pas la totalité d'un tuto trop abondant.
Et cette opération s'effectue sur le forum commun à tous les membres DF, dont nous attendons, avis, critiques et corrections proposés de la part de tous !
Bon, la photo me hèle... Bon we à tous !
Amitié, Joel
Dernière modification par smolski (28-08-2009 04:10:08)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
). Pour moi ça marche, ça me paraît être un excellent compromis entre tout ce qui a été proposé !Enfin, cette opération stratégique pour le wiki des sources.list et consorts a été appelée par des questions redondantes sur ce forum où il appert que les débutants ne lisent pas la totalité d'un tuto trop abondant.
Je ne pense pas que le fait que ce soit trop abondant soit le seul facteur responsable. Je ne mettrais même pas ma main à couper qu'il le soit. Un exemple : la documentation de Gentoo. Parcours-la et tu verras que c'est du lourd : elle est cependant considérée comme étant la meilleure doc jamais écrite pour une distribution GNU/Linux.
Le fait que Gentoo soit réservée à des linuxiens - très - avertis ne change pas la donne, puisqu'à priori ils débutent avec Gentoo. Et je ne pense pas que les utilisateurs de Gentoo aient des prédispositions génétiques à lire de la documentation que les utilisateurs de Debian n'ont pas... 
Je vois deux autres pistes à ce problème :
- Mauvaise visibilté de la documentation ?
- Fainéantise des visiteurs ? (cad : plus facile de poser la question que de chercher ?)
- Un peu des deux ?
- Un peu des trois si on rajoute l'abondance d'informations ?
La question mériterait sans doute d'y réfléchir plus profondément et de consulter nos membres à ce sujet... À suivre
[/Hors-sujet]
« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe
Hors ligne
Le fait que Gentoo soit réservée à des linuxiens - très - avertis ne change pas la donne, puisqu'à priori ils débutent avec Gentoo.
Trés avertis, donc déjà au fait que la doc est une part essentielle pour aboutir réellement à la maîtrise à minima de gentoo !
Nos débutants ne sont avertis de rien, ils viennent d'un monde où le tout cuit dissimule plus qu'il n'enseigne, pire dissimule plus encore le savoir... savoir qui devrait être collectif, comme avec le libre, ce qui permet, et de s'enrichir personnellement, et de l'enrichir à destination de tous.
Amitié, Joel
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Il peut être très intéressant de modifier en même temps le fichier **/etc/apt/apt.conf** : par défaut, l'installation automatique des paquets //recommandés// est activée et vous vous retrouverez vite avec un certain nombre de paquets inutiles qui envahissent votre système. Pour y remédier, on va éditer le fichier **/etc/apt/preferences** (il n'existe pas par défaut) et y mettre ceci :
Correction apportée dans le wiki et le message #25 de ce fil, on va éditer le fichier /etc/apt/preferences, il s'agit bien sûr du fichier /etc/apt/apt.conf. Toute petite distraction de la part de mani.
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
[Hors-sujet]
smolski a écrit :Enfin, cette opération stratégique pour le wiki des sources.list et consorts a été appelée par des questions redondantes sur ce forum où il appert que les débutants ne lisent pas la totalité d'un tuto trop abondant.
Je ne pense pas que le fait que ce soit trop abondant soit le seul facteur responsable. Je ne mettrais même pas ma main à couper qu'il le soit. Un exemple : la documentation de Gentoo. Parcours-la et tu verras que c'est du lourd : elle est cependant considérée comme étant la meilleure doc jamais écrite pour une distribution GNU/Linux.
Le fait que Gentoo soit réservée à des linuxiens - très - avertis ne change pas la donne, puisqu'à priori ils débutent avec Gentoo. Et je ne pense pas que les utilisateurs de Gentoo aient des prédispositions génétiques à lire de la documentation que les utilisateurs de Debian n'ont pas...
Je vois deux autres pistes à ce problème :
- Mauvaise visibilté de la documentation ?
- Fainéantise des visiteurs ? (cad : plus facile de poser la question que de chercher ?)
- Un peu des deux ?
- Un peu des trois si on rajoute l'abondance d'informations ?
La question mériterait sans doute d'y réfléchir plus profondément et de consulter nos membres à ce sujet... À suivre
[/Hors-sujet]
Salut
Voici mes commentaires concernant cette question.
Concernant le wiki, il est essentiel que les textes que l'on y retrouve soient le plus clair et le plus facile à comprendre possible pour ceux qui les lisent. Nous sommes tous d'accord là dessus.
Maintenant, on aura beau tenter de mettre l'accent sur la visibilité du wiki, écrire le mot wiki en grosses lettres grasses, il reste que, la nature humain étant ce qu'elle est, la personne qui a un problème viendra rapidement poser sa question sur le forum. C'est un comportement que l'on rencontre souvent et pas seulement sur ce forum vous en conviendrez.
Pour ma part, je crois que si la réponse à une question se trouve dans le wiki, il ne faut pas hésiter, dans un premier temps, à diriger la personne vers le bon texte. Si le texte de référence est assez long, je ne crois pas que cela pose problème en autant que l'on utilise de la bonne façon le wiki. Je m'explique. Prenons un exemple. Je veux que la personne lise l'explication concernant le fichier sources.list complet pour lenny. Je peux dire que l'information se trouve sur cette page. Mais, encore mieux, je peux lui dire d'aller directement lire cette section. Dans ce dernier cas, on utilise la table des matières du texte du wiki pour diriger la personne au bon endroit. La longueur du texte ne pose plus alors vraiment de problème.
Diriger une personne vers une page au lieu d'une section précise, c'est une erreur que nous faisons tous je crois, moi le premier. Ce n'est que tout récemment que je me suis dit que l'on pouvais faire autrement.
Donc, pour en revenir aux questions posées sur le forum, je crois dans un premier temps qu'il est préférable de commencer par diriger celui qui en pose une vers le wiki si la réponse à sa question s'y trouve. Au lieu de tout répéter et réécrire le texte, au risque d'oublier un truc important, il est mieux de faire référence au texte explicatif. Après tout, on n'a pas écrit ce texte pour rien. Dans le fond tout est dans la façon de faire. On indique le lien vers le wiki puis on invite la personne à revenir vers le forum en disant que cela nous fera plaisir de répondre à ses questions si quelque chose dans le texte n'est pas clair ou ne permet de résoudre le problème. C'est une façon aussi de toujours avoir le wiki à jour et de l'améliorer si nécessaire.
D'autres commentaires suivront.
Martin
Dernière modification par martinux_qc (31-08-2009 01:21:07)
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
Dernière modification par martinux_qc (31-08-2009 01:19:18)
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
Comme j'ai déjà mentionné dans un message ci-haut, j'ai écris mon texte essentiellement en pensant aux branches testing et unstable où le pinning (aller piocher dans une autre branche) est important. De plus, comme j'utilise très peu Lenny, je suis porté à faire moins attention à ce qui la concerne.
Maintenant. J'ai relu mes notes puis démarré sous Lenny pour faire quelques tests, l'option -s de aptitude ou apt-get est bien utile dans ce cas, pour être bien certain de mon coup.
Nous sommes d'accord, je crois, pour dire que nous voulons aller chercher certains paquets dans les dépôts debian-multimedia et lenny-backports, au besoin seulement. Pour les paquets de debian-multimedia, c'est à cause de VLC comme mentionné. Pour lenny-backports, on suit les instructions donnés sur le site. Nous voulons aussi que ces paquets soient mis à jour lorsqu'une nouvelle version des paquets est disponible, nous voulons donc les suivre. Pour ce faire, selon la règle des priorités, il suffit de mettre dans le fichier preferences une priorité de 200 pour ces 2 dépôts.
Pour ma part, j'aime bien utiliser des chiffres rond dans le fichier preferences. Tu as mis des valeurs de 201 et 221 dans ton fichier Mani, mais, en pratique, 200 aurait tout aussi bien fait l'affaire. Et au fait, pourquoi une priorité de 221 (ou 220) pour debian-multimedia ? Toutes mes simulations avec ton fichier preferences ou bien deux fois 200 m'ont donné le même résultat. Il faut dire que dans lenny les mises à jour sont très peu nombreuses. J'avais une priorité de 90 depuis le début pour debian-multimedia et en changeant la valeur pour 200, j'ai eu seulement 3 paquets mis à jour et 1 enlevé avec aptitude (apt-get conservait le paquet).
Avec Lenny, même avec une priorité faible pour debian-multimedia, il faut faire attention aux paquets provenant de ce dépôt. Il se peut qu'en voulant installer une application s'y trouvant celle-ci exige une dépendance provenant de son dépôt, dépendance qui empêchera VLC de bien fonctionner.
Pour les autres dépôts de lenny, il faut que ceux-ci soient sur le même pied, qu'ils aient tous la même priorité. Comme on utilise pas les dépôts des autres branches, mettre une priorité de 990, comme tu l'as fait, ou ne rien mettre, donc conserver la priorité par défaut de 500, reviens au même. Encore une fois, j'ai testé avec ton fichier prefences complet et un autre où il n'y avait pas de priorité 990. Pour ma part, au final, j'ai donc rien mis. Le fichier preferences que j'ai donc adopté pour lenny est le suivant :
S'il y a quelque chose qui m'a échappé ou que tu n'es pas d'accord sur un point Mani, c'est la bonne occasion pour en discuter. Avant d'apporter des corrections dans les textes j'attends ton opinion là-dessus.
Jusqu'à maintenant, dans mes 3 derniers messages, j'ai écris beaucoup de commentaires au fur et à mesure que j'avance dans mon analyse. Toutes ces remarques sont lancées un peu en vrac. J'espère que je ne suis pas trop confus et que vous arrivez à suivre. Dans le cas contraire, on précisera ce qui ne l'est pas.
À la prochaine.
Martin
Dernière modification par martinux_qc (31-08-2009 01:53:02)
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
Pour ma part, j'aime bien utiliser des chiffres rond dans le fichier preferences. Tu as mis des valeurs de 201 et 221 dans ton fichier Mani, mais, en pratique, 200 aurait tout aussi bien fait l'affaire. Et au fait, pourquoi une priorité de 221 (ou 220) pour debian-multimedia ?
Et pourquoi pas ?
Je pense que c'est pour la raison inverse qui fait que toi tu aurais mis 200 : je n'aime pas les chiffres ronds ! Il me fallait juste un nombre entre 101 et 500... Par contre effectivement, les deux peuvent avoir la même priorité.
Sinon pour le reste je n'avais pas pensé à ne pas mettre de priorité pour les dépôts principaux. Mais je suis d'accord avec toi, ça doit fonctionner pareil. En fait c'est le problème des priorités : il y a trop de manières de faire différentes qui arrivent au même résultat !
Si smolski ne voit pas non plus de problème dans ton fichier preferences, je le reprendrai pour le texte sur Lenny (je mettrai les priorités à 200 pour être cohérent avec les recommandations d'usage ("D'un point de vue pratique, il est préférable d'utiliser des chiffres ronds (900, 800, 90…)").
Pour le reste j'y réfléchis : tu as posté nombre de commentaires intéressants qui méritent de s'y attarder !
« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe
Hors ligne
Hors ligne
Dernière modification par smolski (31-08-2009 17:49:24)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
Sinon pour le reste je n'avais pas pensé à ne pas mettre de priorité pour les dépôts principaux. Mais je suis d'accord avec toi, ça doit fonctionner pareil. En fait c'est le problème des priorités : il y a trop de manières de faire différentes qui arrivent au même résultat !
Il peut en effet y avoir plus d'une façon d'arriver au même résultat mais je recherche toujours la plus simple. Dans le cas de lenny, avec seulement les dépôts de cette branche, mettre une priorité de 990 pour stable me semble superflu. Si mettre 990 ou ne rien mettre donne le même résultat dans ce cas-ci pourquoi ajouter une ligne. À moins d'être un peu "craintif" ou tatillon et de vouloir être certain que les priorité sont bien établis. Dans ce cas, il faudrait aussi mettre une priorité pour le dépôt volatile.
Enfin, cela n'est pas commettre une faute grave d'utiliser un fichier preferences avec une priorité de 990 car, en bout de ligne, on arrive au même résultat, au même comportement du fichier preferences. C'est juste une façon de voir les choses.
J'ai hâte de voir ce que tu penses des autres commentaires.
À la prochaine
Martin
Dernière modification par martinux_qc (01-09-2009 03:01:49)
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
PS : J'déballe mes valises de voyage et reviens demain sur l'ensemble des idées copieuses et généreuses de ce fil.
Yop !
Amitié, Joe
Sacré Joel. Même pas pris le temps d'arriver qu'il viens déjà fouiner sur le forum. Il a été agréable au moins ce voyage ?
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
), mais il est arrivé - souvent même - que des membres n'aient jamais fait attention qu'il y avait aussi un wiki.Pour moi, la branche stable se limite à cela. Il n'est pas question d'aller piocher dans les autres branches, surtout pour un débutant. Seul un utilisateur averti pourra se permettre ce genre de chose. Pour les applications plus récentes, il y a lenny-backports. Point. Si une application récente n'est pas dans lenny-backpots, dites-vous qu'il y a une raison. Tout n'est pas "backportable". Certaines dépendances ne peuvent être satisfaites. Donc, si on désire conserver la stabilité de son système, on ne va pas piocher dans testing ni encore moins dans unstable. S'il n'y avait pas le problème avec VLC, on pourrait très bien se passer de fichier preferences pour cette branche ou seulement en avoir un si on utilise lenny-backports.
Pour être sous Lenny, je ne peux qu'être d'accord avec toi : le pinning est un non-sens sur une stable. Et même quand on maîtrise bien son système, c'est quasiment impossible, la libc6 y passe trop souvent. Il est simplement dommage que certaines applications ne soient pas backportées (par exemple Gimp 2.6 n'est pas dans lenny-backports alors qu'il se compile très facilement).
Ton paragraphe mériterait d'être intégré à la page du sources.list de Lenny (moyennant adaptation bien sûr) car il me semble que c'est un point important.
Donc la question de la branche stable est relativement simple à traiter. On le constate d'ailleurs avec le texte de Mani. Il est court et fait le tour de la question. À la place de la section "Clés et authentification", on pourrait trouver un lien vers la section du traite de ce sujet ailleurs car elle est commune à toutes les branches. Cela fait doublon. C'est un petit détail que l'on pourrait toujours discuter. Sinon, pour le texte dans son ensemble, je crois que l'approche de Mani est la bonne.
Ça me va très bien, une page pour chaque chose et chaque chose à sa place ! Ça permettrait au passage d'intégrer un peu plus d'explications sur les clés (ainsi qu'une autre méthode pour les installer, très intéressante mais beaucoup plus "barbue", qui traîne quelquepart dans mes notes ).
L'approche proposée par Joel s'applique selon moi pour un texte assez long. J'ai copié par exemple le texte originale que j'ai produit dans OpenOffice. En format lettre sans rien modifié de la mise en page, le texte fait 15 pages. Dans ce cas, j'aurais pu diviser le texte en plusieurs sections, lire plusieurs pages différentes dans le wiki. Par contre, si on fait cela, il faut selon moi mettre un lien à la fin d'une page vers la page suivante pour bien montrer qu'il y a une suite à lire, on dirait page suivante. Que la page que l'on vient de finir de lire n'est pas complète en soi, qu'il y a une suite à lire pour la bonne compréhension du sujet traité. Si on conserve l'approche de Joel c'est ce qu'il faut faire pour la branche stable, au lieu du Préalable, et bien indiquer sur la dernière page qu'au final, on se retrouve avec le fichier sources.list présenté sur cette page.
Je ne suis pas convaincu par cette approche qui me paraît peu adaptée à un wiki. Par contre un rappel sous forme de liens au à la place de Page suivante/Page précédente, oui. En début de page les pages qu'il vaut mieux avoir lu avant, en fin de page celles qu'on peut lire après, et même au fil du texte celles qui sont pertinentes (l'exemple des clés d'authentification me vient en tête).
Mais il me semble essentiel qu'une page doit traiter entièrement et seulement de son sujet, ce qui d'ailleurs m'amène à une réflexion à propos de mon texte sur Lenny :
- soit on l'éclate comme proposé (avec les clés à part).
- soit on l'intègre dans une page à part qui ne donnerait que des conseils de base, avec juste ce qu'il faut d'explications (en renvoyant vers les autres pages du wiki pour approfondir le sujet), pour bien commencer avec Debian (cette page pourrait d'ailleurs être mise en avant au tout début du wiki).
Et d'ailleurs je me dis que d'avoir les deux n'est pas forcément une mauvaise chose et que des doublons pouvaient être tolérés dans ce but (et uniquement dans celui là).
Pfiou, à vous !
« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe
Hors ligne
Dernière modification par smolski (02-09-2009 20:02:20)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Mani a écrit:
En début de page les pages qu'il vaut mieux avoir lu avant, en fin de page celles qu'on peut lire après, et même au fil du texte celles qui sont pertinentes (l'exemple des clés d'authentification me vient en tête).
Mani a écrit :
Mais il me semble essentiel qu'une page doit traiter entièrement et seulement de son sujet
Voilà pour moi la formule qu'il faut adopter. Un sujet, une page. On doit retrouver sur celle-ci toute l'information pertinente qui concerne le sujet.
Au tout début, de la page, on place un ou des liens vers la ou la page que l'on suggère fortement de lire pour une meilleure compréhension du sujet. À la fin, un ou des liens vers la page ou les pages qui traitent d'un autre sujet mais relié directement à celui dont il est question. Par exemple, à la fin de la page du sources.list lenny pour débutant mettre un lien vers l'explication du fichier sur la page du fichier /etc/apt/apt.conf.
Au fil du texte, on aurait aussi des liens dans le cas où l'explication est assez longue. Dans le texte de mani, sur le fichier sources.list pour débutant, l'explication sur les clés est assez courte, donc on peut la reprendre dans son texte, même si elle fait doublon. Pour un truc beaucoup plus long on met un lien.
C'est le plan qu'il faut adopter selon moi. En ce sens, Joel tu vas dans la bonne direction.
Remarque concernant ta dernière essaie de composition.
1) OK
2) Le fichier /etc/apt/apt.conf. Sujet important mais je le mettrais à la fin. Il est pertinent peu importe la branche utilisée.
Après je vois les choses comme cela :
On a La GESTION et l'ADMINISTRATION DES DEPOTS DEBIAN
POUR LES DÉBUTANTS :
je mettrais ensuite
NIVEAU AVANCÉ :
où l'on retrouve les sections suivantes:
Explication de l'utilisation du fichier preference
Explication du pinning
Le fichier sources.list et le preference pour une testing
Le fichier sources.list et le preference pour une sid
Il est important pour moi de retrouver sur une même page les fichiers sources.list et preferences pour une branche, l'un en dessous de l'autre. Comme cela, c'est plus clair. De plus, les deux fichiers sont directement reliés, ils vont ensemble. Il ne faudrait pas qu'une personne utilise le fichier sources.list complet pour testing/sid sans avoir le bon fichier preferences. Sinon, on simplifie les choses et, pour sid, on met un fichier sources.list avec seulement les entrées pour sid. C'est ce que certaines personnes font d'ailleurs.
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne
Mani a écrit :
Il est simplement dommage que certaines applications ne soient pas backportées (par exemple Gimp 2.6 n'est pas dans lenny-backports alors qu'il se compile très facilement).
Une solution possible pour ceux qui s'y connaissent en compilation et qui ont un serveur ftp accessible, c'est de compiler une application, d'en faire un .deb donc, et de le rendre accessible pour d'autres. Je sais, par exemple, qu'une personne a déjà fait cela pour la version 0.9 de VLC. Donc c'est possible lorsqu'on en a les moyens.
"L'éducation vise à former des citoyens pas trop tatas et non pas à envoyer le plus de tatas possible à l'université."
Pierre Foglia (Journaliste à la retraite à La Presse)
Note : au Québec, le mot tata a un sens péjoratif qui sert à désigner une personne un peu idiote ou insignifiante. D'où les expressions familières : Espèce de grand, de gros tata! Être, avoir l'air tata.
Hors ligne