Depuis que j’ai commencé à vraiment me relire et faire des recherches pour savoir par exemple comment un verbe se conjugue, je les vois beaucoup plus. J’espère qu’au fil du temps je vais bien m’améliorer 
[quote=“lol”][quote=“wetaskiwin”]Chercher à comprendre, c’est commencer à désobéir.[/quote]Très désobeissant(e) ce soir ! 
Je vois passer dans les “topics” plein de sources.list avec des mélanges de branches… Et tout plein de problèmes…
Au risque de me répéter… Choisissez votre branche et restez-y bien accrochés, sans essayer d’attraper celle d’à côté :smt003
C’est simpliste (peut-être même simplet) mais j’assume. Ce n’est pas prévu à l’installation, même en mode expert 
Ma Lenny, c’est une Lenny. 100%
Ma Sid c’est une Sid. 100%[/quote]
Si je suis sous linux, c’est justement pour pouvoir “personnaliser” un système qui m’offre suffisamment de souplesse et une communauté suffisamment active pour m’aider à le faire. Tu es libre de faire une “pure” lenny ou une pure “sid”, mais pourquoi marteler (presque ordonner) que c’est ça qu’il faut faire et (presque) rien d’autre…
Le monde à toujours avancé parce que certains ont osé sortir du purisme, c’est vrai pour linux depuis ses débuts, non ?
Et oui, j’aime bien désobéir - N’en déplaise à mon ministre 
…parce que je suis curieux devrais-je lui répondre !
[quote=“sebiseb”]Si je suis sous linux, c’est justement pour pouvoir “personnaliser” un système qui m’offre suffisamment de souplesse et une communauté suffisamment active pour m’aider à le faire. Tu es libre de faire une “pure” lenny ou une pure “sid”, mais pourquoi marteler (presque ordonner) que c’est ça qu’il faut faire et (presque) rien d’autre…
Le monde à toujours avancé parce que certains ont osé sortir du purisme, c’est vrai pour linux depuis ses débuts, non ?
[/quote]
Tu as parfaitement raison sur plusieurs points :
Chacun est libre de faire ce qu’il veut;
Si tu es sous Gnu/Linux, c’est pour être libre;
C’est grâce aux découvreurs et penseurs que nous savons que la terre n’est pas plate…
Je pense simplement que c’est donner un bâton pour se faire battre que d’essayer, souvent en vain, de faire mieux que ce qui est prévu par les développeurs… Tu ne penses pas que c’est déjà extraordinairement personnalisable comme ça ?
Et en fait de personnalisation j’ai plutôt l’impression que ce qui t’intéresse, c’est de bénéficier d’avancées sans en prendre complètement les risques… Je suis en stable, mais je veux les derniers programmes de Expérimental…
Regarde le sources.list du fil “configuration” (il est dans les messages récents, tu le trouvera facilement). Tu ne penses pas que les problème auraient pu être évités avec une Debian “mono” branche ?
Je suis fasciste parce que je pense que le système tel qu’il est se suffit déjà à lui même et qu’il offre un choix déjà énorme ?
Je sais que ma position t’énerve… désolé ! 
:smt002
C’est exactement ce que je voulais répondre au msg qui précède la réponse de MisterFreez …[/quote]
J’imagine que vous faites référence au
La réponse ( de … )était qu’on pouvait tout de même installer un paquet "avec apt-get/aptitude install foo -t branche (du moment que toutes les dépendances se trouvent dans la branche donnée en argument ou la branche suivie bien sûr)."
L’avantage me semble être de pouvoir connaitre les versions se trouvant sur divers dépôts (apt-cache policy est top de côté là) sans prendre le risque d’installer quoi que ce soit, tout en se réservant la possibilité de le faire exceptionnellement par un apt-get install paquet -t branche.
Cependant les mises à niveau ultérieures du paquet (issu de Pin-Priority: -10) ne se feront pas à moins de relancer la commande : apt-get install paquet/branche (man apt_preferences)
Ce qui me perturbe encore, c’est la place exactes et le fonctionnement des dépôts “Unofficial Multimedia Packages”.
Difficile donc de choisir la priorité que j’ai mise légèrement inférieure aux dépôts “officiels”.
Mais sont ils officiels ou pas ? that is the question
car ils seraient apparemment inclus dans
Si j’ai bien compris, l’Archive (a) prend le pas sur l’Origine (o) qui prend lui-même le pas sur le Label (l)
Va falloir que je me penche sur les divers (o) existants pour bien comprendre.
Des retours sur mes modifs?
Ben quand je disais, quelque part dans un fil récent, que les “forts en linux” ne sont pas toujours bons pédagogues, c’est tout à fait justifié là.
Tu as fait de smodifs, j’y suis allé voir et je n’ai lu que l’ajout en tête de gondole.
Si tu voulais qu’on remarque bien ces modifs, il aurait été plus malin de les écrire en couleur différente.
Salut,
J’avais déjà fait remarqué ce problème il y a un an :
Ben quand je disais, quelque part dans un fil récent, que les “forts en linux” ne sont pas toujours bons pédagogues, c’est tout à fait justifié là.
Tu as fait de smodifs, j’y suis allé voir et je n’ai lu que l’ajout en tête de gondole.
Si tu voulais qu’on remarque bien ces modifs, il aurait été plus malin de les écrire en couleur différente.[/quote]
La modif n’est qu’un ajout (long) au début du fil sur le fichier preferences, c’est tout. Il n’est pas question de modifier les écrits de Matt, rajouter une précision signalant le problème et un exemple d’alternative me parait suffisant.
Plutôt sur le 2ème post de Mattotop.
Je sais bien que je suis un peu naze en la matière (donc soyez tolérant et excusez un simple d’esprit d’être casse-burnes) mais :
Mattotop met des préférences de stable à 990 (Pin-Priority: 990)
Pourtant il est dit quelquepart sur ce forum : Attribuer une priorité comprise entre 500 et <990 pour la branche suivie et la/les branche(s) comportant des paquets aux versions =< à la branche suivie.
Pourquoi <990 ? Car lorsque l’on utilise l’option -t pour installer des paquets d’une autre branche que celle suivie celle-ci devient temporairement la branche par défaut (APT::Default-Release “branche”
et à donc une priorité de 990.
On comprend donc aisément qu’avoir une priorité => 990 pour la branche suivie perturbe l’option -t
et aussi man apt_preferences :
990 < P <=1000
et
500 < P <=990fait référence à < et > mais pas =
???. Donc perso je me méfie des P = 1000, P = 990, P = 100, P = 0
[quote=“fran.b”]
La modif n’est qu’un ajout (long) au début du fil sur le fichier preferences, c’est tout. Il n’est pas question de modifier les écrits de Matt, rajouter une précision signalant le problème et un exemple d’alternative me parait suffisant.[/quote]
Ok, dans ce cas là, j’ai lu, mais moi, je n’appelle pas ça une modification mais une adjonction ou une mise en garde.
Sans pour cela juger du bien-fondé d’une vrai modification, mais je t’approuve quand même de ne pas le faire sans l’aval de Matt.
Matttttttttttttttttttttttttt — qu’est-ce que tu fous, c’est fini les vacances 
Oui mais cela concerne surtout Stable et se sont surtout les bibliothèques (comme libc6) qui y posent soucis.[/quote]
Il me semble qu’à un moment on avait émis l’idée de définir une priorité > 1000 pour la libc, pour s’assurer qu’elle ne soit pas prise par dépendance dans un autre dépôt que le dépôt « prioritaire ». Mais ça n’a jamais été rajouté au tuto. Oubli ou mauvaise idée ?
[quote=“lol”]
Je pense simplement que c’est donner un bâton pour se faire battre que d’essayer, souvent en vain, de faire mieux que ce qui est prévu par les développeurs… Tu ne penses pas que c’est déjà extraordinairement personnalisable comme ça ?
Et en fait de personnalisation j’ai plutôt l’impression que ce qui t’intéresse, c’est de bénéficier d’avancées sans en prendre complètement les risques… Je suis en stable, mais je veux les derniers programmes de Expérimental…[/quote]
Les développeurs ont bien prévu que l’on puisse mixer les versions, puisqu’ils ont validés le système du couple dépôts / priorités !?
[quote=“lol”]
Regarde le sources.list du fil “configuration” (il est dans les messages récents, tu le trouvera facilement). Tu ne penses pas que les problème auraient pu être évités avec une Debian “mono” branche ?[/quote]
Non, j’avais installé temporairement une sid, et en tant que simple utilisateur j’ai eu plein de soucis pour le maintien des paquets et des dépendances. Depuis l’installation de lenny (stable), et en adaptant au fur et à mesure de ce que je comprends les priorités à mes dépôts pour installer des paquets en dehors de la version installée je n’ai plus de problème de maintenance, je peux travailler de manière collaborative, et tout va bien, alors pourquoi ne pas faire partager mon expérience, et aider ceux qui ont besoin d’adapter leur outil un peu comme moi ?
[quote=“sebiseb”]
Non, j’avais installé temporairement une sid, et en tant que simple utilisateur j’ai eu plein de soucis pour le maintien des paquets et des dépendances. Depuis l’installation de lenny (stable), et en adaptant au fur et à mesure de ce que je comprends les priorités à mes dépôts pour installer des paquets en dehors de la version installée je n’ai plus de problème de maintenance, je peux travailler de manière collaborative, et tout va bien, alors pourquoi ne pas faire partager mon expérience, et aider ceux qui ont besoin d’adapter leur outil un peu comme moi ?[/quote]
200% d’accord avec toi, Gnu/Linux n’existerait pas sans… Je pense que tu as mal interprété mes reflexions.
Mes interventions répétées, exaspérantes, et insistantes ne sont là que pour souligner qu’il ne faut pas oublier de préciser en début du T&A qu’un sources.list “normal” est mono-branche.
Et que tout changement est complexe et dangereux…
D’autres que moi le pense aussi…toolinux.com/lininfo/toolinu … art-de-mal
Je pense avoir été entendu…
Ben ce n’est pas ce que j’ai constaté avec ma sid ni avec mes testing précédentes.
Exemple avec libtalloc1.apt-cache policy libtalloc1
libtalloc1:
Installé : 1.3.1-2
Candidat : 1.3.1-2
Table de version :
*** 1.3.1-2 0
988 http://ftp.fr.debian.org testing/main Packages
100 /var/lib/dpkg/status
1.2.0~git20080616-1 0
987 http://ftp.fr.debian.org stable/main Packages
Ce paquet n’est pas présent en sid. Il est peut-être remplacé par libtalloc2 présent en sid que j’ai donc installé.
Puis j’ai tenté unapt-get remove libtalloc1
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
libempathy23 libepc-ui-1.0-2 libglib-perl ekiga python-gst0.10 gcalctool
apache2-utils libpango-perl libarchive1 gnome-nettool libepc-1.0-2
libgtk-vnc-1.0-0 nautilus tesseract-ocr python-notify libtelepathy-glib0
pkg-config obex-data-server gucharmap cheese libgpac0.4.5 evolution-exchange
gnome-bluetooth libspectre1 app-install-data gnome-power-manager
totem-plugins gnome-screensaver rhythmbox telepathy-mission-control
python-gdata gedit python-gtksourceview2 system-config-printer
libmissioncontrol-client0 apache2.2-bin evince-common libapr1 gnome-themes
libtrackerclient0 seahorse libgnome2-perl empathy libempathy-common
libempathy-gtk19 totem-common libaprutil1-ldap gvfs-bin vinagre swfdec-gnome
seahorse-plugins nautilus-data libgpod4 libdvbpsi5 gnome-user-share
libgalago3 gedit-plugins libtelepathy-farsight0 libgnome-bluetooth2
gedit-common gnome-themes-extras libopal3.6.4 libdmx1 libcryptui0 libvlc2
gdm-themes fast-user-switch-applet arj libaprutil1-dbd-mysql
gnome-volume-manager apache2.2-common gtk2-engines
libgtksourceview2.0-common libkpathsea4 libt1-5 eog gdm
libgtksourceview2.0-0 libgnome2-vfs-perl ogmtools gnome-backgrounds
python-sexy python-xdg libupnp3 libgtk2-perl libevince1 vino evince
gnome-app-install libapache2-mod-dnssd libmissioncontrol-server1
libtelepathy2 totem-gstreamer aften libpt2.6.4-plugins libiso9660-7
libepc-common libpt2.6.4 libcdio-paranoia0 synaptic gpac python-gdbm
gnome-core dmz-cursor-theme python-evolution python-pkg-resources
libempathy-gtk-common libgmyth0 gconf-editor vlc-data gnome-system-tools
libtar libcairo-perl hamster-applet libvlccore2 libvcdinfo0 libavahi-ui0
libaprutil1 p7zip-full gstreamer0.10-tools totem-mozilla
libgnome2-canvas-perl tesseract-ocr-deu file-roller libopenobex1
libspeexdsp1 transmission-gtk python-rdflib sound-juicer libgmythupnp0
Veuillez utiliser « apt-get autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
gnome gnome-desktop-environment gvfs-backends libgnomevfs2-extra
libsmbclient libtalloc1 libwbclient0 mencoder mozilla-mplayer mplayer ogmrip
ogmrip-ac3 ogmrip-doc ogmrip-mpeg ogmrip-profiles ogmrip-video-copy smplayer
smplayer-themes smplayer-translations vlc vlc-nox
0 mis à jour, 0 nouvellement installés, 21 à enlever et 1 non mis à jour.
Après cette opération, 59,2Mo d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ?
J’ai bien sur refusé.
Où est mon erreur si un source list mono branche en sid se suffit à lui même ?
De la même manière, la testing est toujours incomplète et ne se comprend que par testing+stable ou testing+sid.
d’où le$ cat /etc/debian_version
squeeze/sid pour squeeze ou sid que le sources.list soit mono-branche ou pas…
[quote=“talogue”][…]
Ce paquet n’est pas présent en sid.[/quote] 
[quote]http://packages.debian.org/sid/libtalloc1[/quote]Excuse moi, il est dans sid ce paquet… Tout comme le 2
[quote]http://packages.debian.org/fr/sid/libtalloc2[/quote] Je n’ai pas bien compris ta démo…
[quote=“fran.b”]De la même manière, la testing est toujours incomplète et ne se comprend que par testing+stable ou testing+sid.[/quote]D’accord avec toi. C’est ce que je voulais démontrer.
Je pense que le sources.list de T&A et les préférences qui vont avec est trop “touffu”.
De mon point de vue il faudrait proposer un truc plus simple qui n’offre peut-être pas toutes les possibilités mais qui serait plus sur.
Par exemple : stable de base + backport
testing de base + stable et/ou sid en renfort
et enfin sid de base + testing et stable voire experimental.
Les préférences proposées devraient à mon sens rester égales à version égale.
Les multimédias pourraient aussi être proposées en expliquant les avantages et inconvénients et les différents pining selon le comportement désiré.
Enfin, pour ceux qui veulent un sources.list long comme un jour sans pain pour essayer tout et n’importe quoi avec un fichier preferences de compétition ben… qu’ils lisent le man et qu’ils se débrouillent.
Je n’ai pas toutes les compétences pour proposer un sources.list et un preferences adapté à tous les cas mais je veux bien faire des propositions au moins pour sid et testing.
[quote=“lol”]Excuse moi, il est dans sid ce paquet… Tout comme le 2[/quote]libtalloc1 est en sid mais dans les debports et en architecture m68k. Pas en i386 ou amd64 !
[quote=“lol”]Je n’ai pas bien compris ta démo…[/quote]C’est portant simple : si je supprime ce paquet uniquement présent en stable ou testing ben je flingue ma sid.
J’ai installé le deb libtalloc2 juste pour voir si ce paquet remplaçait libtalloc1. Ben non !
Cordialement et sans esprit de polémique. Juste pour faire avancer le scmilblick.
[quote=“talogue”][quote=“lol”]Excuse moi, il est dans sid ce paquet… Tout comme le 2[/quote]libtalloc1 est en sid mais dans les debports et en architecture m68k. Pas en i386 ou amd64 !
[quote=“lol”]Je n’ai pas bien compris ta démo…[/quote]C’est portant simple : si je supprime ce paquet uniquement présent en stable ou testing ben je flingue ma sid.
J’ai installé le deb libtalloc2 juste pour voir si ce paquet remplaçait libtalloc1. Ben non !
Cordialement et sans esprit de polémique. Juste pour faire avancer le scmilblick. [/quote]
Je suis pas froissé, seulement un peu nul…
J’aime bien l’esprit avec lequel tu débat !
Bon SID se sert d’un paquet d’une branche inférieure. Moi ça ne me pose pas de problème, c’est transparent.
Mon sources.list est 100% SID, et je n’ai pas à me compliquer la vie… Evidemment que les branches au dessus de Lenny utilisent des paquets des branches inférieures, mais cela se fait “naturellement” (les développeurs sont sympas…) sans fichier préférences ? si ?