logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#26 27-08-2009 09:44:20

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut mani,

Effectivement, c'est une belle option pour le tuto des sources.list de base...

Felicitation ! big_smile

Pour le fichier preferences de la fin, je crois qu'il vaut mieux mettre :

900

pour préserver ce niveau qui est utilisé par une mise à jour forcée... J'ai plus en tête le détail... Voit martin pour ça...

Perso, je ne défends pas plus que ça celui que j'ai proposé et mis. cool

Vous faites comme vous voulez les amis ! smile

Moi, j'photo de nouveau ces prochains temps... wink

Amitié, Joel

saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#27 27-08-2009 10:00:13

mani
Road-Runnerus digestus
Lieu : Au bout du bout
Distrib. : Buster
Noyau : Linux 4.19
(G)UI : Plasma
Inscription : 20-06-2007

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Merci Joel ! smile

Disons que je me dis que quelqu'un qui débute sur Debian prendra sûrement Lenny et donc aura toutes les cartes en main en une seule page pour commencer sereinement.

Je n'ai plus en tête le détail des priorités non plus, ce sont celles dont je me sers en tout cas. Attendons la réponse de notre spécialiste !

Bonnes photos l'ami ! smile

Matthieu

« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe

Hors ligne

#28 27-08-2009 13:08:15

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Bon, je pose une sauvegarde ici de la version 1 et j'ajoute celle de mani dans le wiki à la suite en version 2.

Ce sera plus parlant pour tout le monde.

Nous pourrons rectifier au final, en supprimant la (les) version supperflue.

Si vous autres membres avez un oeil, un avis, voire une idée (peut-être de synthèse), qu'ils ne se gênent pas... On est tous preneurs et gagnants de cete collaboration à plusieurs...
Ici le tuto duo : http://debian-facile.org/wiki/manuel:sources.list

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âââ ! big_smile

Amitié, Joel


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#29 27-08-2009 13:17:09

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Aaaaaah c'est effectivement bien plus clair ainsi...

Et à cette lumière :

Je me demande mani comment tu vas amener l'explication des autres fichiers sources.list où si tu vas en faire l'impasse...
Ou si nous devons considérer que le pinning est la seule autre solution ?
Perso je reste à croire qu'il est nécessaire de garder les autres sources.list détaillés comme dans la version 1.

Ensuite, si nous devons garder autant de commentaires et non renvoyer chaque point abordé par un lien vers une explication détaillée, je ne suis pas sûr que nous aurons gagné au change par rapport au tuto généraliste en cours actuellement.

Je me permet de renvoyer cet avis pour comparer à la formule du site de captnfab, qui, il me semble a trouvé un modus vivendi trés acceptable et clair là :
http://wiki.chezlefab.net/tuto_nix/installation_squeeze

De cette aération des informations avec des liens.
Libre au visiteur de les suivre ou de poursuivre s'il possède déjà l'information sur le point du lien...

Amitié, Joel

Dernière modification par smolski (27-08-2009 13:29:31)


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#30 27-08-2009 15:00:02

mani
Road-Runnerus digestus
Lieu : Au bout du bout
Distrib. : Buster
Noyau : Linux 4.19
(G)UI : Plasma
Inscription : 20-06-2007

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Tu veux parler des sources.list de Squeeze et de Sid ? Il est tout a fait possible de les mettre dans une page à part non ?

D'une manière générale, je pense qu'il est préférable de mettre l'accent sur Lenny, puisque le wiki est destiné à des débutants qui choisiront de ce fait plutôt la version stable. Après il faut aussi intégrer d'une manière ou d'une autre l'excellent tuto de Martin sur le pinning.

Le lien que tu as mis propose une mise en forme qui n'est à mon avis pas adaptable avec notre documentation. Les liens qu'il propose se trouvent sur la première page et ne renvoient eux-mêmes que très peu vers d'autres pages, un peu comme un livre avec des notes de bas de pages : on lit la note et on retourne ensuite au texte.

Utiliser sa méthode pour le wiki, en continuant la comparaison avec un livre, consisterait à renvoyer vers une note de bas de page qui renverrait vers une annexe qui renverrait vers un glossaire... bref, on ne s'en sort plus !

Ou alors, il faudrait réadapter la page d'accueil du wiki pour limiter le nombre de niveaux de liens. Dans ce cas je propose 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 (en regardant par exemple ce qui se fait chez les autres : Ubuntu, Fedora, Archlinux...).

Pour enfin avoir une doc française à la hauteur de Debian ! smile

Matthieu

« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe

Hors ligne

#31 27-08-2009 16:50:21

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Mani a dit :

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 ! wink
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

#32 27-08-2009 21:13:28

mani
Road-Runnerus digestus
Lieu : Au bout du bout
Distrib. : Buster
Noyau : Linux 4.19
(G)UI : Plasma
Inscription : 20-06-2007

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

smolski a écrit :

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 ! smile

smolski a écrit :

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.

smolski a écrit :

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 !

smolski a écrit :

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 :

Généralités
[...]
Un sources.list complet pour Lenny
[...]
Sources.list alternatifs :
- lien vers le sources.list du libriste convaincu
- lien vers le sources.list backports
- lien vers le sources.list multimedia
[...]
Clés et authentification
[...]


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. neutral

smolski a écrit :

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.

smolski a écrit :

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... wink


« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe

Hors ligne

#33 28-08-2009 01:30:28

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut Joel et Mani

Bon je vois que la discussion a beaucoup avancée aujourd'hui. C'est bien. Par contre cela fait beaucoup de lecture, tant dans ce fil de discussion que dans le wiki. Les propositions de la nouvelle forme des textes du wiki sont intéressantes et demandent réflexion. Aussi, en espérant qu'il n'y ait pas trop de chambardement d'ici 2 ou 3 trois, je désire prendre le temps de libre tout cela à tête reposée d'ici dimanche soir et vous faire part de mes commentaires et réflexions. Je vais prendre du même coup le temps de vérifier 2 ou 3 trucs avant de répondre à la question concernant les priorités du fichier preferences.

À la prochaine
Martin

"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

#34 28-08-2009 03:42:57

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Hop !

mani a écrit :

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 ! wink

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

#35 28-08-2009 08:44:19

mani
Road-Runnerus digestus
Lieu : Au bout du bout
Distrib. : Buster
Noyau : Linux 4.19
(G)UI : Plasma
Inscription : 20-06-2007

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Ho capito !

Merci de ces explications supplémentaires (encore ! big_smile). Pour moi ça marche, ça me paraît être un excellent compromis entre tout ce qui a été proposé !

On s'revoit la semaine prochaine ? Histoire de laisser le temps à Martin de digérer tout ça... de toute façon avec le soleil de prévu ce WE, vous n'allez pas me voir beaucoup par ici ! cool

[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... lol

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

#36 28-08-2009 21:16:06

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Ah mani :

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

#37 30-08-2009 03:39:37

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut

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

#38 30-08-2009 04:20:58

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

mani a écrit :

[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... lol

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

#39 30-08-2009 18:59:03

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut

La suite.

Pour en ajouter une couche. Une documentation abondante n'est pas un problème en soit. Tout en dans la façon de présenter les choses. Vous connaissez le cours pour débutants que l'on retrouve sur le site du zéro. Tout est bien divisé en de nombreuses sections mais on retrouve beaucoup d'informations sur une page. Par exemple. Tout est dans la façon de voir les choses.

Autre point à considérer. Selon moi, il y a deux types de personnes qui viennent sur le forum. Le premier type cherche à résoudre un problème précis. Il veut uniquement une réponse à sa question ou être dirigé vers la bonne section du wiki. Le second type, plus curieux, voudra comprendre les choses, apprendre comment fonctionne son système et sera prêt à lire ce qu'on lui propose. Pour lui, une documentation plus ou moins fourni et abondante ne sera pas un problème en autant que le sujet est bien présenté et agréable à lire. C'est pour ce second type de personne que le wiki doit être conçu. Les autres, on risque de ne pas trop les voir sur le forum, jusqu'au prochain problème. Ce n'est pas une critique juste mon opinion.


En ce qui concerne notre wiki, il est bon de faire un certain ménage car on trouve certaines informations à deux endroits différents. On doit s'assurer d'avoir qu'une explication se trouve au bon endroit, et seulement là, et de faire un lien vers celle-ci lorsque nécessaire. Il est essentiel d'enlever les doublons. C'est inutile et permet de mettre à jour plus facilement le wiki. On peut modifier un texte à un endroit et oublier que l'on traite de la même chose ailleurs. On pourrait alors avoir des informations contradictions ou plus à jour à un endroit.

Le sujet traité ici qui concerne les fichiers sources.list et preferences est très vaste. Certaines explications sont communes à toutes les branches et doivent être mises dans des sections à part. D'autres concernent uniquement une branche et doivent se retrouver sur une page dédiée. La division des sections telle que proposée est donc une bonne chose.

Le grand texte que j'ai mis dans le wiki concernait surtout les branches testing et unstable. En ce qui me concerne, la situation de la branche stable est assez simple. Au départ, il y a trois dépôts. Le dépôt de la branche elle-même (avec main contrib et non-free), celui du dépôt security et, enfin, celui de debian-multimedia qui est nécessaire si on veut pourvoir lire ses DVD et autres trucs multimédias propriétaires. Par la suite, on prends connaissance de l'existence des dépôts volatile et lenny-backports et on décide ou non de les intégrer dans notre sources.list. Le dépôt volatile est plus ou moins utile. Le dépôt lenny-backports est plus intéressant bien que pas connus de tous, surtout les débutants.

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.

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.

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 vois l'approche de Mani comme un texte explication alors que Joel propose une approche plus pédagogique, par étape, qui amène petit à petit le lecteur vers le résultat final. Les deux approches se défendent. Tout dépend du but que l'on vise.

Pour les branches testing et unstable, il faut utiliser une approche qui permet de couvrir tout le sujet tout en ayant des sections bien découpées. Un peu comme Joel le propose. J'aime bien aussi comment le site du Zéro présente son cours. Pour ces branches, il faut ajouter au moins les dépôts d'une autre branche pour se tirer d'embarras. Pour testing par exemple, il faut au moins ajouter ceux de la branche stable et avoir ceux de unstable est un plus. Pour ces branches, pour bien comprendre ce que l'on fait, il faut comprendre ce que sont les dépôts, les fichiers sources.list et preferences, comment fonctionne le pinning, ce qu'est le fichier apt.conf. Bref, pour moi, tous ces sujets son reliés entre eux et il faut prendre le temps d'en faire le tour. Donc, oui, beaucoup de lecture mais pour qui veut apprendre cela ne constitue pas une barrière.

À suivre

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

#40 31-08-2009 00:51:41

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

À propos du fichier preferences de Mani :

Package: *
Pin: release o=Debian,a=stable
Pin-priority: 990

Package: *
Pin: release o=Unofficial Multimedia Packages,a=stable
Pin-priority: 221

Package: *
Pin: release o=Backports.org archive,a=lenny-backports
Pin-priority: 201


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 :

Package: *
Pin: release o=Unofficial Multimedia Packages,a=stable
Pin-priority: 200

Package: *
Pin: release o=Backports.org archive,a=lenny-backports
Pin-priority: 200


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

#41 31-08-2009 08:54:53

mani
Road-Runnerus digestus
Lieu : Au bout du bout
Distrib. : Buster
Noyau : Linux 4.19
(G)UI : Plasma
Inscription : 20-06-2007

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut Martin !

Merci pour tous ces commentaires ! Je prends le temps de tout digérer avant de répondre, pour l'instant je réagis juste à ça :

martin_mtl a écrit :

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 ? wink
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 ! smile


« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe

Hors ligne

#42 31-08-2009 10:27:26

n3os
Modérateur
Lieu : /Debian/Home/neos
Distrib. : Sid
Noyau : 2.6.35
(G)UI : e17
Inscription : 14-07-2007

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Hello,

pour les novices, peut-être indiquer pourquoi commenter les "deb-src" et à quoi elles servent.
un explication du style,

Les lignes commençant par "deb-src" peuvent être commenter avec un # en début de ligne, ou supprimer si vous ne comptez pas compiler des paquets, elles concernent les paquets sources, elles vous seront utiles seulement si vous comptez télécharger le nécesssaire d'un paquet pour en modifier un ou des paramètres et recréer un binaire.

Hors ligne

#43 31-08-2009 17:43:41

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut neos !

Effectivement, je pensais que le lien vers :
http://debian-facile.org/wiki/manuel:de … t_security

suffirait, mais il n'y est pas indiqué grand chose quant à la raison de l'activation ou désactivation de ces lignes deb-src...

Ton texte ci-dessus y a trouvé ainsi une belle et bonne place ! Hop hop hop.... smile

Merci de ton attention...

Il est à noter, que cette remarque de neos indique bien que la complexité du sujet général de la gestion des paquets se doit d'éclater en multiples pages plutôt que de stationner en groupe longéliformes pour y maintenir cohérence et actualités diverses...

Amitié, Joel

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. wink

Yop !

Amitié, Joe

Dernière modification par smolski (31-08-2009 17:49:24)


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#44 01-09-2009 01:44:49

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut

Correction dans le wiki et dans ce fil de discussion pour SOURCES.LIST (Version 2), sur la ligne deb-src du dépôt lenny-backports, il manquait un e à non-free.

Martin

"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

#45 01-09-2009 01:57:37

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

mani à écrit :

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

#46 01-09-2009 04:00:03

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

smolski a écrit :

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. wink

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

#47 02-09-2009 13:27:34

mani
Road-Runnerus digestus
Lieu : Au bout du bout
Distrib. : Buster
Noyau : Linux 4.19
(G)UI : Plasma
Inscription : 20-06-2007

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut à tous !

Le recul étant pris, voici mes réactions aux propos de Martin. smile

Concernant la visibilité du wiki, ça m'a rappelé un texte que j'avais lu il y a longtemps et que j'ai eu du mal à retrouver : Comment poser les questions de manières intelligentes. Hormis le fait que je le trouve assez élitiste (et que l'auteur m'a l'air d'avoir de sacrés chevilles), je pense que ça peut être une bonne idée d'en écrire un pour DF. À l'heure actuelle, il y a une page dans le wiki, une sur le site et une (au moins) sur le forum.

L'idée serait d'inciter les débutants à parcourir le wiki avant toute chose, par exemple en y mettant quelques liens vers des pages indispensables (ex : la commande su et l'utilisation de # et de $ dans les commandes qui sont proposées). Je n'imagine pas que ça réglera tous les syndromes RTFM/STFW (que certains mériteraient vraiment parfois, heureusement qu'on est sympa ici wink ), mais il est arrivé - souvent même - que des membres n'aient jamais fait attention qu'il y avait aussi un wiki.

Sinon pour le reste de ton commentaire sur la visibilité et l'organisation du wiki, je suis entièrement d'accord et n'ai rien à y ajouter. De toute manière si cette question fait débat autant lui en ouvrir un sujet dédié ! smile

Pour en venir au sujet :

Martin a écrit :

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.

Martin a écrit :

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 wink ).

Martin a écrit :

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 ! smile


« Those who dream by day are cognizant of many things which escape those who dream only by night. »
- Edgar Allan Poe

Hors ligne

#48 02-09-2009 17:10:51

smolski
quasi...modo
Lieu : AIN
Distrib. : backports (buster) 10
Noyau : Linux 4.19.0-8-amd64
(G)UI : gnome
Inscription : 21-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Arfff... Nous tournons autour du pot sans jamais nous décider à mettre la patte vraiment dedans ! tongue

Bon, les acquis :

Séparer les explications des fichiers complémentaires ainsi :

     dépôts
     apt.conf
     sources.list
     preferences
     pinning
     ...

Le problème est au niveau des sources.list.

L'option de mani  un sources.list type débutant à copier et coller me paraît la plus belle et simple des choses.
Donc, nous aurions :

     DF s'engage : sources.list type pour débutant. Version stable. (la version de mani textuelle.)

puis :

     dépôts
     apt.conf
     sources.list type Détail. (les versions de joel mais sur une seule page, en progressant logiquement et en utilisant les noms de release.)
     preferences
     pinning

Ceci, afin de modifier au plus léger le tuto actuel.

Comme j'ai commencé, je vous mets cette idée (qui paraît recouper les vôtres) en visuel dans le tuto wiki en construction.
Rappel :
http://debian-facile.org/wiki/manuel:in … ots_debian

Yop !

Dernière modification par smolski (02-09-2009 20:02:20)


saque eud dun (patois chtimi : fonce dedans)

Hors ligne

#49 03-09-2009 02:17:55

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

Salut

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

#50 03-09-2009 02:23:46

martinux_qc
Anar
Lieu : Montréal (Québec)
Distrib. : Debian 11 stable
Noyau : Linux 5.10.0-8-amd64
(G)UI : XFCE 4.16
Inscription : 12-10-2008

Re : wiki fichier refonte sources.list - preferences - pinning en cours...

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

Pied de page des forums