On le sait tous, Debian Sid, connue aussi sous le nom de Debian unstable, est une branche particulière de cette distribution. Il n'y a pas de release, pas de période de freeze, cette branche peut donc être qualifiée de rolling-release. S'il ne viendrait à l'idée d'aucun administrateur compétent de l'installer sur un serveur de production ou même sur des desktops de production il semble néanmoins que ce soit un système de choix pour des machines personnelles utilisées comme desktop, là où on est prêt à devoir à contourner certains bugs… des bugs nouveau chaque jours… pour suivre de plus près le développement upstream et ainsi profiter des dernières fonctionnalités de ses logiciels favoris.
C'est le choix que j'ai fait depuis plusieurs années, l'un des problèmes que j'ai rencontré c'est le volume extrêmement important des mises à jour. Même avec une connexion plus que potable en débit, le fait de dépaqueter et configurer tous les packages à mettre à jour lors d'un apt-get upgrade est assez lourd. Soit on le fait régulièrement et c'est chiant, soit on le fait moins régulièrement et c'est tout aussi chiant…
Il semble aussi complètement stupide d'automatiser la mise à jour lorsque l'ordinateur ne fait rien d'autre, par exemple la nuit, à part la récupération de la liste des packages disponibles (update), car dans ce cas aucun moyen de lire les avertissements produits par apt-listbugs et apt-listchanges…
Je me suis donc dit qu'une solution pouvait être de ne mettre à jour que certains packages, les programmes end user, le système APT permettant ainsi de ne mettre à jour que les autres packages (bibliothèques) seulement si nécessaire. Dit autrement, si la nouvelle version de ton éditeur favoris dépend de libedit2 (>= 2.03), que tu as déjà libedit2 2.03, c'est pas la peine de mettre libedit2 à jour à la version suivante, bien qu'elle soit déjà disponible, parce que tu mets à jour cet éditeur…
J'écris donc ce journal pour partager avec vous un script et la liste des packages que j'utilise afin d'avoir vos commentaires sur ces derniers. Je souhaiterais également inciter d'autres utilisateur à partages leur expérience et leurs astuces pour l'utilisation au quotidien d'une Debian Sid. Cette Debian qui n'est toujours, officiellement, à n'utiliser dans aucun contexte et juste une sorte de sas pour la mise au point des branches testing et stable…
Le script :
#!/bin/bash
apt-get update
apt-get -y install $(cat packages)
apt-get -y autoremove
apt-get clean
Le fichier packages :
amule
aqemu
audacity
bash
bc
busybox
calf-plugins
claws-mail
claws-mail-plugins
claws-mail-smime-plugin
cmake
cmt
dash
dbus
dbus-x11
deluge
deluged
e2fslibs
exim4
ffmpeg
file-roller
flashplugin-nonfree
gedit
gimp
gimp-data-extras
git
grub-pc
gtk3-engines-xfce
gtk2-engines-xfce
iceweasel-l10n-fr
imagemagick
initramfs-tools
k3b
libklibc
libreoffice-l10n-fr
libvlc5
libvlccore8
libqt4-dev
lvm2
nginx
okular
openssh-server
orage
pidgin
python3
q4wine
qt5-default
shorewall
swh-plugins
systemd
systemd-ui
systemd-sysv
thunar
thunar-volman
unbound
util-linux
virt-manager
vlc
wine
wine64
# SID vs Arch
Posté par gnumdk (site web personnel) . Évalué à 7.
Perso, je suis passé sous Debian sid et l'avantage sur Arch, c'est que tu n'est justement pas obligé de faire des mises à jours régulières…
Pourtant, dans l'esprit rolling release, arch suit vraiment mieux les nouvelles versions des logiciels mais en fait beaucoup trop… Arch n'a aucune cohérence, on package une nouvelle version d'un paquet même si ça doit casser d'autres paquets…
Dernier exemple en date: https://bugs.archlinux.org/task/44557
J'ai fini par saturer… Debian sid, c'est le juste milieu :)
[^] # Re: SID vs Arch
Posté par Reihar . Évalué à 3.
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/gpg-2.1.patch?h=packages/seahorse
Je ne sais pas si c'est suffisant mais le mainteneur de seahorse a, au moins, commencé à faire quelque chose.
[^] # Re: SID vs Arch
Posté par xcomcmdr . Évalué à 4.
Euh, c'est pas du tout mon expérience. D'abord il y a un dépôt testing, qui n'est pas utilisé pour tout certes, mais qui est utilisé pour vérifier justement qu'on casse rien.
Et quand ça casse d'autres paquets, une nouvelle version des paquets concernés sont disponibles avec la mise à jour (exemple : la mise à jour de libpng, où ça n'a cassé que les paquets installés via des scripts AUR qui n'avaient pas été mis à jours par leurs mainteneurs malgré les avertissements).
Et si on "packageait une nouvelle version d'un paquet même si ça doit casser d'autres paquets", croit moi que je l'aurais senti passer lors de la mise à jour de KDE 4 vers Plasma 5. Or, je suis passé à Plasma 5.3 et KDE Frameworks 5.9 sans que rien ne casse.
Pas mal pour une distribution qui casse tout pour la mise à jour d'un paquet. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: SID vs Arch
Posté par gnumdk (site web personnel) . Évalué à 3.
Je parle de paquets mis à jour alors que les projets upstream en dépendant ne l'ont pas été… C'est pas les packageurs Arch qui code sur les softs qu'ils packagent…
Je te parle pas de réussir à packager KDE5.
[^] # Re: SID vs Arch
Posté par xcomcmdr . Évalué à 3. Dernière modification le 08 mai 2015 à 11:30.
Exemple ?
Certes, mais la plupart du temps, une recompilation (pas faite par toi) + publication d'une nouvelle version du package suffit.
J'ai jamais eu une mise à jour du type que tu décris en tout cas.
Et pour prendre un exemple, je connais beaucoup de projets qui, même sur Arch, sont restés sur la SDL 1.2 alors que la SDL 2.0 est arrivée (DOSBox par exemple).
Et pourtant c'est une transition qui est loin d'être simple, et les mainteneurs n'ont pas juste balancé Plasma 5 comme ça, ce qui me fait d'autant plus douter de l'existence des mises à jours "ça casse ou ça casse" que tu décris.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: SID vs Arch
Posté par Spyhawk . Évalué à 4.
Seahorse et le support PGP… Le passage à KDE 5 n'à rien à voir, on parle pas de packaging mais de passer à la version suivante alors qu'upstream n'a pas encore fait son boulot, quitte à casser des petites choses.
Les deux approches sont différentes (perso l'approche d'Arch "marche où crève" me convient très bien), Arch fait relativement du bon boulot, mais non, ça ne sert à rien de faire l'autruche sur les défauts des qualités intrinsèques d'Arch.
[^] # Re: SID vs Arch
Posté par xcomcmdr . Évalué à 2. Dernière modification le 08 mai 2015 à 13:12.
Je ne fais pas l'autruche, mais dire que Arch balance les mises à jours sans penser aux conséquences et que ça pète dans tous les coins et que Arch n'a aucune cohérence, c'est pas la même chose que de dire que Arch a les défauts de ses qualités.
Tout ça parce que il y a UN truc qui pète on chie dessus. Faudrait apprendre à se calmer.
Et puis l'attitude "marche ou crève" n'est pas vraie partout. Y'a encore plein de projets qui utilise la SDL 1.2 à la place de la SDL 2.0, même sous Arch, et aucun mainteneur de Arch n'a essayé de faire le forcing (en tout cas à ma connaissance).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: SID vs Arch
Posté par Spyhawk . Évalué à 2.
C'est vrai, d'où l'incohérence d'Arch :P
Encore une fois, Arch fait du bon boulot en proposant plusieurs versions de librairies dans les dépôts binaires lorsque c'est vraiment nécessaire (comme SDL, Lua, ..), mais c'est loin d'être fait pour tout (et à raison amha). Ca arrive de temps en temps qu'un logiciel perde une fonctionalité parce qu'un projet upstream ne suit pas, mais c'est normalement jamais très grave ni ne dure très longtemps.
Et oui, faire la comparaison avec KDE 5 est, pour moi, du total autruchage dans le sable. Y'a un juste milieu entre "ca pète dans tous les coins" et "j'ai rien eu avec cette grosse mise à jour donc ça n'arrive pas". Y'a pas qu'un côté qui devrait se calmer, parce que l'argumentation unilatérale n'est jamais très crédible.
[^] # Re: SID vs Arch
Posté par Reihar . Évalué à 3.
À noter que quand on met une grosse lib à jour sous Arch, type qt4 -> qt5, on fait les choses bien. Il y a eu une bonne période de transitions, où on en parlait sur les mailing lists et les modifications à effectuer pour continuer à dépendre de qt4.
[^] # Re: SID vs Arch
Posté par Spyhawk . Évalué à 4.
Oui, Arch fait très bien les choses lorsque qu'il s'agit de gros changements. C'est plus les petites choses qui posent un problème potentiel, comme une nouvelle version d'une lib qui casse un logiciel spécifique.
[^] # Re: SID vs Arch
Posté par xcomcmdr . Évalué à 3.
Ah merci !
On voit que c'est tout de suite beaucoup moins grave que :
Mais la vérité est moins drôle j'imagine. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: SID vs Arch
Posté par Spyhawk . Évalué à 5.
Oh, je ne nie pas que la formulation de gnumdk me semble un poil exagérée, mais j'imagine que ça dépend de ce qu'il entendait par "cohérence" ici :)
[^] # Re: SID vs Arch
Posté par gnumdk (site web personnel) . Évalué à 0.
J'entends par cohérence de tester les paquets… Tous les paquets devraient passer par testing.
C'est bien mon problème, j'ai du installé Arch 4 fois ces deux derniers mois parce que j'aime beaucoup cette distrib mais trop de bugs qui n'existent pas ailleurs (décoration SSD en ce moment sous GNOME…).
[^] # Re: SID vs Arch
Posté par sanao . Évalué à 4.
Réinstaller 4 fois en 2 mois Arch à cause de paquets foireux? Tu ne serais pas en train d'exagérer?… Je suis très curieux d'avoir le détail de tes problèmes et pas juste des remarques vagues.
[^] # Re: SID vs Arch
Posté par gnumdk (site web personnel) . Évalué à 2.
J'ai parlé de paquet foireux? J'ai parlé de bug…
Des exemples:
- "suspend to ram" qui plante aléatoirement… Quand tu codes sur ton laptop, au bout d'un moment, ça gonfle…
- Xorg qui segfault régulièrement…
- je sais plus, plein de petits trucs chiant…
Depuis le sortie de GNOME 3.16, Arch est devenue inutilisable pour moi…
Pas un problème de GNOME car je n'ai pas ces problèmes sous Fedora 22
[^] # Re: SID vs Arch
Posté par sanao . Évalué à 1.
Tu as fait des rapports de bugs? Tu as posé des questions sur le forum? Parce que là j'ai comme l'impression que tu as pleins de problèmes sans trop les avoir identifier. Et je ne vois pas en quoi tout réinstaller règlerai les problèmes?
Après, visiblement, tu as laissé tombé Arch… C'est un moyen comme un autre de régler ses problèmes.
[^] # Re: SID vs Arch
Posté par groumly . Évalué à 5.
C'est le moyen le plus courant de régler ses problemes dans un domaine ou l'offre est particulierement abondante, effectivement. S'attendre a ce que les utilisateurs fassent le boulot de QA de la distro, ca va 5 minutes.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: SID vs Arch
Posté par gnumdk (site web personnel) . Évalué à 1.
Pas besoin, les problèmes sont souvent déjà identifié sur le forum… Faut pas me prendre pour un débile non plus, je sais remonter les problèmes sous Arch:
https://bugs.archlinux.org/index.php?string=&project=1&type[]=&sev[]=&pri[]=&due[]=&reported[]=&cat[]=&status[]=&percent[]=&opened=gnumdk&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=&do=index
[^] # Re: SID vs Arch
Posté par xcomcmdr . Évalué à -2.
Jamais le cas chez moi. Donc c'est pas un problème de Archlinux, mais un problème de Archlinux avec ton matériel ou une version d'un paquet foireuse.
Jamais le cas chez moi. Donc c'est pas un problème de Archlinux, mais un problème de Archlinux avec ton matériel ou une version d'un paquet foireuse.
Allez au pire, quelques parties de Plasma 5 sont toujours en anglais. ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: SID vs Arch
Posté par David Demelier (site web personnel) . Évalué à 2.
Je pense que le slogan qui caractérise bien Arch c'est "Tester c'est douter". La dernière fois j'ai voulu tester GNOME 3 dessus, j'ai eu plusieurs applications avec des bibliothèques manquantes. Chouette début :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: SID vs Arch
Posté par Anonyme . Évalué à 2.
Ah bon ? Le dernier paquet en date qui casse c’est xserver-xorg-video-intel sur sid, et ça fait un an que j’ai eu aucun problème de paquet cassé avec Arch.
Bullshit à la puissance Bullshit. Peut-être que ce qui casse pour toi, c’est des changements dans la configuration des logiciels que tu utilises.
Bon et qu’on soit bien d’accord, je ne vante pas les méthodes de ArchLinux ni les défaillances des packagers, je dis juste que ce que tu racontes, c’est bullshit et que ça arrive aussi avec Sid. Sauf que Sid a le mérite d’être explicitement indiquée comme « unstable ».
[^] # Re: SID vs Arch
Posté par gnumdk (site web personnel) . Évalué à 0.
Non, ça n'arrive pas dans SID.
J'ai du contacter plusieurs fois des mainteneurs de paquets Arch parce qu'il avait mis une version de dev dans Arch… Le dernier en date était shotwell…
Cela n'arrivera jamais sous Debian car il n'y a pas de concours du packageur le plus rapide… Souvent, le paquet arrive dans Arch alors que y'a pas eu d'annonce de la part des développeur…
[^] # Re: SID vs Arch
Posté par ZeroHeure (site web personnel) . Évalué à 4.
Il y a plein de paquets Debian tirés des forges logicielles, sans annonce des développeurs, c'est facile à voir ils ont une date dans le numéro de version. J'imagine qu'il y a souvent des bonnes raisons, mais pas toujours : je me souviens des sites d'Abiword et de Scribus qui recommandaient de ne pas utiliser les paquets Debian. Sous Debian comme sous Arch il y a des mainteneurs qui font des conneries.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Quelques conseils d'ordre général
Posté par Reihar . Évalué à 6. Dernière modification le 08 mai 2015 à 01:47.
Pour mitiger la consommation de bande passante, tu pourrais télécharger les paquets la nuit, si apt le permet. Sinon, il doit bien y avoir un moyen de bidouiller les caches locaux en téléchargeant les paquets à la main, mais j'espère quand même qu'il dispose de cette fonctionnalité.
Ensuite, pour ce qui est de la consommation, il est possible d'altérer la priorité des processus lancés à l'aide d'outils tels que nice et schedtool, de manière à ce que la décompression de paquet n'impacte pas les performances du système. C'est relativement simple à effectuer, quitter à devoir écrire quelques scripts.
Je te recommande vivement d'explorer ce genre de piste parce que les upgrades partielles, c'est un coup à mettre une lib majeure à jour sans mettre à jour la moitié des paquets qui en dépendent, ce qui peut s'avérer très rigolo.
Edit:
On peut en effet juste télécharger les paquets.
-d, --download-only
Download only; package files are only retrieved, not unpacked or installed.
[^] # Re: Quelques conseils d'ordre général
Posté par Olivier (site web personnel) . Évalué à 5.
Personnellement, je fais précéder mes commandes "apt-*" ou "aptitude" par
nice -n 20 ionice -c 3
Le gestionnaire de paquet a le moins de priorité CPU et I/O (disque dur) possible.
Pour les mises à jour, j'ai un alias :
# Ou sinon tu peux te raser la barbe
Posté par bubar🦥 (site web personnel) . Évalué à 8.
Et utiliser une « distribution de filles » (insèrez ici tout adjectif dénigrant un autre groupe social que celui des barbus avec des haches)
Mon niveau de tolérance envers mon ordinateur étant tombé très très bas, chez moi, je n'ai plus aucune envie de bidouiller pour que ça fonctionne. Un système qui fonctionne sans poser plein de questions, qui fait ses mises à jour sans rien casser, et qui propose les dernières versions des logiciels end user.
Fedora.
[^] # Re: Ou sinon tu peux te raser la barbe
Posté par Michaël (site web personnel) . Évalué à 5.
Et FreeBSD – mais bon ok, c'est pas Linux :D
[^] # Re: Ou sinon tu peux te raser la barbe
Posté par Astaoth . Évalué à 2.
Tu veux parler de l'absence de Steam, Skype, ou encore Chromium dans les dépôts de bases ? Et de l'impossibilité de trouver la dernière version de Chromium (un LL quand même) dans un dépôt tier ? Et à chaque mise à jour du kernel, j'ai un module différent des additions de virtualbox (Fedora en tant qu'invité) qui ne compile pas, jusqu'au dernier kernel. J'ai également croisé des bugs "marrant" avec cettedistro avec un certains kernel, bug non reproduit sur le même ordi avec d'autres distros et divers kernel dont certains dans la même version.
C'est surement une bonne distribution, mais pas aussi parfaite que ce que tu as l'air de penser.
Emacs le fait depuis 30 ans.
# Debian mon amour
Posté par kursus_hc . Évalué à 10.
Pour l'utiliser sur ma machine principale depuis de longues années, je tempérerais : Debian Sid n'est pas plus buggée que Arch, Suse ou Fedora. Les "bugs nouveaux chaque jours" se retrouvent sans problème dans Experimental, mais dans Sid il faut quand même aller les chercher (des exemples ?). D'ailleurs pour qui veut être "au plus près d'upstream" Sid n'est pas le meilleur plan : il n'est pas rare de voir arriver des versions avec plusieurs mois de retard, justement parce Debian Sid n'est pas un fourre-tout bleeding edge qui nécessite de croiser très fort les doigts pour que tout fonctionne. Malgré sa réputation c'est une distribution extrêmement solide.
Effectivement Debian Sid n'est officiellement recommandée pour rien, et c'est dommage. Je pense que les devs ne veulent pas s'embêter avec le support de Sid, qui le mériterait pourtant, en plus du fait que le mot "stable" a une signification particulière chez Debian et qu'il ne veulent sans doute pas l'affaiblir. Pour moi, et à mon avis pour eux aussi, Sid n'est pas qu'un sas vers Testing, c'est une vraie distrib qui roxe et qui est bien supérieure à la norme.
Pour info, puisque je tombe souvent sur des mauvaises interprétations, la famille Debian est souvent analysée comme tel :
Experimental : Bleeding edge et nombreux bugs, souvent cassée
Sid : Presque bleeding edge et nombreux bugs, souvent cassée
Testing : Un peu dépassée, quelques bugs, presque stable
Stable : Stable, quelques bugs
Alors que la réalité serait plutôt :
Experimental : Bleeding edge et nombreux bugs, souvent cassée
Sid : Presque bleeding edge et quelques bugs, jamais cassée
Testing : Un peu dépassée, beaucoup de bugs, de temps en temps cassée
Stable : Stable, quelques bugs
Le détail qu'on rate souvent est que Testing a pour unique but de rendre Stable stable, et si ce but demande de casser Testing pendant 3 semaines ça sera le cas. Sid (ou "Unstable") a pour but de mener sa vie et d'être aussi performante que possible, sans dépendance à une autre branche, ce qui la rend BIEN plus solide que Testing.
[^] # Re: Debian mon amour
Posté par jon . Évalué à 6.
jamais cassée, je n'irais pas jusque là, ça m'est arrivé une poignée de fois en fait … en une douzaine d'années, bon OK.
Ceci dit, je suis d'accord avec toi sur le reste, cette Sid a bien mauvais réputation, alors que ça marche vraiment bien en pratique.
[^] # Re: Debian mon amour
Posté par _kaos_ . Évalué à 3.
Salut,
Comme je l'avais exprimé précédemment, c'est aussi mon avis concernant la sid. Parfois broken, rarement longtemps, surtout si c'est sévère.
De mon côté, j'use aussi (misérablement mal, très certainement) parfois de l'apt-pinning (sur les machines que je ne veux pas passer complètement en sid) ou de mise en hold de paquets (repositories en différentes versions).
Ce n'est pas vraiment à recommander, au sens où la tâche de résolution de dépendances automatique peut facilement plus se vautrer comme une grosse loutre et effectivement, là, il faut prendre le temps de faire ses mises à jour.
Cependant, et c'est mon point de vue, ces machines n'ont absolument pas besoin d'être "up" 24/24 7/7, juste un peu "bleeding-edge". je peux les casser, tant pis. Je trouve l'argument (ici volontairement caricatural) du
un peu facile.
Quelque part, c'est abandonner sa vie face à l'outil.
Pour faire un parallèle, quel serait la qualité d'un conducteur qui ne vérifierait pas sa jauge d'essence avant un long trajet ? Ou régulièrement l'état de ses pneus, du niveau d'huile ? Ou de temps en temps ferrait un "check-up" chez le garagiste ?
C'est peut-être une comparaison capilo-tractée, mais en tout cas, pour moi, je trouve le moyen pour me dégager du temps et faire régulièrement ce "check-up" de ma sid.
Matricule 23415
[^] # Re: Debian mon amour
Posté par rewind (Mastodon) . Évalué à 6.
Oui, pas plus tard qu'hier, j'ai dû me cracher dans les mains pour résoudre un problème un peu gênant : plus de réseau. Enfin en apparence seulement parce que j'arrivais à pinguer des adresses IP mais pas des noms d'hôtes. En fait, ça venait d'une mise à jour de NetworkManager. La nouvelle versions considérait que le paquet resovconf devait être installé alors qu'il n'est pas dans les dépendances du paquet Debian correspondant. Du coup, pas de résolution DNS. Et bien c'est sacrément handicapant ! Parce que plus rien ne marche : plus de apt, plus de web, plus rien. J'ai dû bricoler le resolv.conf à la main pour avoir à nouveau du réseau et mettre à jour. Heureusement, ce bug est arrivé à d'autres et le mainteneur avait corrigé ça vite fait.
[^] # Re: Debian mon amour
Posté par kursus_hc . Évalué à 3.
Il y a des bugs des bugs qui cassent des choses, comme pour toutes les distribs d'ailleurs, mais la correction met rarement plus de quelques heures à arriver (d'ailleurs pour celui que tu cites, si l'on omet les fuseaux horaires, le bug a été corrigé avant d'être signalé ;).
C'est vrai que c'est une bonne pratique avec Sid, voire avec n'importe quelle distribution, de ne pas mettre à jour dans la minute où les paquets arrivent. Avec cette précaution on se prémunit d'une vaste majorité des problèmes potentiels.
[^] # Re: Debian mon amour
Posté par FDF (site web personnel) . Évalué à 1.
Du coup, en phase avec le journal d'origine, ce serait pas mal de prévoir un script qui "refuse" de mettre à jours si les paquets ont moins de 48 heures!
C'est faisable? apt ramène les heures de mise à jour?
[^] # Re: Debian mon amour
Posté par _kaos_ . Évalué à 2. Dernière modification le 08 mai 2015 à 12:18.
Salut,
'dredi, toussa. Je zou, et je re.
Rien à péter de l'aptitude d'apt !
zou… --->[]
[]----> re
hum.
Avec un peu de prévoyance, et sans même se poser la question de si l'option est possible (je ne sais pas), en reprenant les avis exprimés plus haut, il est possible de :
- faire un update pour lister les nouveautés,
- télécharger sans installer les paquets.
Donc un peu de planning perso et se dire, ok, y'a ça, ça devrait me prendre X temps, je met Y de marge, j'ai mon mirroir et au pire je fonce sur le dépôt si besoin.
Peut-être une tâche en cron ? Un script lancé en prévision justement du planning ?
En effet, et je suppose que ça ne marche qu'à moitié cette solution, ça ne s'adapte pas à la situation "j'avais un méga truc de prévu et c'est annulé à la dernière minute donc la j'ai du temps".
D'un autre côté, si l'on a du temps, du coup… Bin autant le prendre et faire les choses, non ?
Matricule 23415
[^] # Re: Debian mon amour
Posté par vv222 (site web personnel) . Évalué à 2.
J’ai pendant longtemps utilisé une méthode similaire :
_apt-get update && apt-get upgrade -dy
_24h de délai
_apt-get upgrade && apt-get update && apt-get upgrade -dy
_24h de délai
_etc.
De cette façon je laisse le temps aux bugs les plus évidents d’être rapportés avant d’appliquer mes mises-à-jour.
La seule raison pour laquelle je ne suis plus ce schéma aujourd’hui est que je suis passé du côté de ceux qui rapportent les bugs, justement pour les éviter à mon moi d’hier qui apprécie son confort.
[^] # Re: Debian mon amour
Posté par rewind (Mastodon) . Évalué à 2.
Oui, c'est vrai que généralement, la correction arrive vite. Surtout pour des paquets aussi utilisés que NetworkManager.
Sauf qu'on ne sait pas de quand date la mise à jour. Typiquement, je fais un update/upgrade tous les 2-3 jours en moyenne, et si je tombe (comme hier) sur la mise à jour foireuse qui n'a pas encore de correction, et bien je ne le sais pas avant d'avoir installé. apt-listbugs sert à ça aussi. Mais bon, quand on utilise sid, pour moi, on sait qu'on peut tomber sur ce genre de cas, donc on fait avec. Sinon, on prend testing.
[^] # Re: Debian mon amour
Posté par kursus_hc . Évalué à 7.
Tout à fait d'accord, même si je ne connais aucune distribution que l'on peut mettre à jour sans crainte à 30 minutes du rendez-vous de sa carrière.
Il faut tordre le cou à cette idée reçue. Debian unstable est plus stable que Debian testing.
[^] # Re: Debian mon amour
Posté par Yannick . Évalué à 2.
Pour éviter ce genre de problèmes, tu peux utiliser
apt-listbugsqui te prévient s'il y a des problèmes graves dans un paquet avant de l'installer. Bien sûr, cela ne fonctionne que si le problème a été rapporté avant que tu n'installe le paquet…[^] # Re: Debian mon amour
Posté par Anonyme . Évalué à 4.
Je suis tellement d'accord avec toi.
J'ai mis longtemps à faire le pas vers sid, justement à cause de cette réputation qu'à sid d'être buggué et réservé au barbus. Réputation que j'ai moi-même contribué à diffuser jusqu'à ce qu'un intervenant ici même me remette les idées en place, chose qui m'a incité à installer sid sur mon laptop pour constater que non seulement ça marchait très bien, que je n'avais plus à attendre 3 semaines qu'un paquet buggué arrive en upstream, et qu'il n'y avait plus de paquets qui disparaissaient comme par magie (sous testing, lorsqu'on s'approche de la release, les paquets que les mainteneurs ont peur de ne pas pouvoir maintenir sautent, ce fut le cas de docker récemment.
Je n'ai quasiment jamais eu à faire face à un problème bloquant, l'utilisateur de apt-listbug suffit à se prémunir de la majorité des gros bugs qui peuvent survenir.
[^] # Re: Debian mon amour
Posté par claudex . Évalué à 4.
Ce qui m'a déçu en sid, ce sont des résolutions de dépendances qui ne sont pas possible et donc, impossible d'installer un paquet. Chose que je n'ai jamais rencontré en testing. Par contre, ce n'est pas arrivé souvent, juste 2-3 fois et ça a suffit à me faire passer à testing. Par contre, j'ai un pinning sid à 100 pour les paquets qui n'existent pas en testing.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian mon amour
Posté par gnumdk (site web personnel) . Évalué à 2.
Pourtant de mon expérience, il y a plus souvent de dépendances cassées en testing quand sid… Comme quoi ;)
[^] # Re: Debian mon amour
Posté par jyes . Évalué à 4. Dernière modification le 11 mai 2015 à 10:24.
Ce serait très étonnant…
Bien sûr il y a toujours des exceptions, mais en temps normal les dépendances cassées dans « testing » sont impossibles. C’est d’ailleurs la seule règle de migration dans « testing » : un temps de maturation et toutes les dépendances déjà présentes. Sauf grosse migration, « testing » n’est qu’une Sid avec du retard et une garantie de dépendances cohérentes. Après si par cassées, tu veux dire qui ne marchent pas, ça arrive, plutôt moins souvent qu’en Sid, mais là ce n’est pas une règle appliquée par un robot alors cela relèvera de la perception de chacun.
[^] # Re: Debian mon amour
Posté par gnumdk (site web personnel) . Évalué à 1. Dernière modification le 11 mai 2015 à 13:06.
Testing breaks less often than Unstable. But when it breaks, it takes a long time for things to get rectified. Sometimes this could be days and it could be months at times.
Unstable changes a lot, and it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.
[^] # Re: Debian mon amour
Posté par claudex . Évalué à 7.
C'est pour ça aussi que j'apt-pin avec sid. Sachant, qu'il est plus facile d'upgrader ses paquets vers sid pour résoudre des problèmes de dépendance que de downgrader vers testing.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Debian mon amour
Posté par Anonyme . Évalué à 2.
Ça t'es arrivé souvent ? Parce que personnellement, ce genre de cas ne s'est jamais produit, j'ai pas le souvenir de ne pas avoir pu installer un paquet à cause d'un soucis de dépendance, les seuls soucis de ce genre apparaissent lors de mise à jours (encore en ce moment, les paquets xorgs-* subissent un soucis de dépendance pour les mise à jour).
[^] # Re: Debian mon amour
Posté par claudex . Évalué à 3.
Merci de lire mes commentaires jusqu'au bout.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# un truc que je n'arrive pas à comprendre.
Posté par hervé Couvelard . Évalué à 10.
Qui peut avoir besoin d'une machine qui a les toutes dernières versions de chaque logiciel installé et qui ne veut pas passer un peu de temps à la maintenir ?
Parce que je côtoie un peu de monde, mais je n'ai pas encore vu un spécimen de la sorte. J'ai vu plein de gens qui veulent les toutes dernières versions de logiciels qu'ils utilisent un fois par mois pour faire une opération qui pourrait probablement être réalisée avec un version vieille de 3 ans. J'ai vu plein de personnes qui en font une sorte de snobisme genre je suis à la pointe de la pointe.
Ah si j'ai vu des développeurs qui utilisent des versions de lib même pas stable pour… je sais pas trop et qui du coup obligent les utilisateurs à passer aux dernières versions des dernières versions pour souvent une plus valus bien faible pour les emmerdes.
Parce que pour LE logiciel qu'on utilise quotidiennement, une version compilé en statique est bien suffisante non ?
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Tout à fait d'accord.
J'aime rappeler qu'on a envoyé des gens sur la Lune avec des ordis et des programmes moins puissant que nos calcucatrices.
Il y a peu de raisons valables pour mettre à jour, à part la sécurité, la compatibilité (import des documents de MSOffice par exemple) et des grosses difficultés dont on espère qu'elles soient résolues (genre avec Nepomuk ou avec kmail et plein de comptes imap). Mais la perpétuelle course à l'échalotte c'est un trait humain ; c'est avec l'expérience (ou l'âge) qu'on devient plus tempéré.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Marotte ⛧ . Évalué à 3.
Il me semble même qu'ils avaient également des tas d'employés occupés à calculer/vérifier des calculs à la main… (enfin à la règle à calculer)
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par François (site web personnel) . Évalué à 2.
Tout à fait. C'était le cas dans tout centre nécessitant des calculs, y compris en France bien entendu. Souvent des femmes, elles faisaient et vérifiaient des calculs dont elles ne savaient souvent pas à quoi ils servaient. Comme des couturières ou des blanchisseuses et elles pouvaient être appelées les "calculettes".
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Je ne sais pas si ils avaient des tas d'employés pour vérifier, mais en tout cas la développeuse en chef du système de guidage d'Apollo (pour l'alunissage) était Margaret Hamilton, qui a co-inventé des concepts de programmation, comme l’exécution asynchrone, la gestion des priorité des tâches etc.. L'OS du système du guidage était une petite merveille pour l'époque.
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par xcomcmdr . Évalué à 3. Dernière modification le 10 mai 2015 à 12:39.
Tu veux dire que je vais installer Debian Stable quand je serais vieux ?
Plutôt crever !
Sérieusement, j'utilise Arch pas tellement pour le côté rolling releae, mais surtout parce que j'en avais assez de bricoler avec des PPAs sous Ubuntu, et de devoir faire des mises à niveau (et sur Debian Stable, ce sera le même problème pour les mises à niveau).
Avec Arch, je met à jour au fil de l'eau toute l'année, plutôt que de faire une grande opération de mise à niveau casse gueule tous les 3 trois ans, et de devoir me demander si j'ai pas foutu le bordel avec les PPAs. :/
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par ZeroHeure (site web personnel) . Évalué à 7. Dernière modification le 10 mai 2015 à 15:22.
Ben ça va sans doute te surprendre mais il y a des gens, même des gens expérimentés hein, et même — mais j'espère que tu es bien assis — des modérateurs et des compagnes et des enfants de modérateurs, qui ont des postes de travail sur Debian stable.
C'est en effet très pratique : tout marche bien, il y a peu de mises à jour (ce qui libère la faible bande passante disponible à la campagne), les jeux fonctionnent tout seuls pour les enfants, administration is a breeze et Papa peut tester tout ce qu'il a sauté les années précédentes dans ses revues préférées…
PS : c'est quoi les PPA ? un truc dont j'ai jamais eu besoin ? :-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par xcomcmdr . Évalué à 3.
Un truc qui évite d'avoir des logiciels obsolètes, ou qui permet d'avoir ffmpeg (le vrai) à la place de cette merde de libav (heureusement sous Arch on a bien compris que ffmpeg n'était PAS obsolète. ;-) )
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Je n'ai aucune compétence pour juger de l'un ou l'autre projet (ffmpeg / libav), et sans rentrer dans la polémique ici libav marche très bien il n'y a jamais eu de raison pour changer vers ffmpeg — fournit par le dépot de Christian Marillat, pas besoin de PPA ! :-)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Michaël (site web personnel) . Évalué à 1.
Un PPA est une personal package archive. Ce sont des dépôts de paquets personnels, qui permettent de distribuer facilement des paquets non intégrés aux dépôts personnels. Par exemple dans le mien il y a des paquets pour Ubuntu de quelques logiciels que j'écris. L'intérêt est de pouvoir accéder rapidement à des mises à jours ou à des versions de développement si on en a besoin.
Coté technique, on prépare un paquet source qu'on upload sur une ferme de compilation avec
dputet les gentils robots préparent les paquets binaires. (Mhh, probablement encore un mauvais tour desystemdcette histoire de paquets binaires.)[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par ZeroHeure (site web personnel) . Évalué à 3.
C'était de l'ironie…
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Michaël (site web personnel) . Évalué à 2.
Que j'ai prise à mille-pour-cent au pied de la lettre! :)
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Michaël (site web personnel) . Évalué à 1.
Pour la partie applicative je te suis totalement, mais lorsqu'on développe on n'a parfois pas trop le choix dans la version de la bibliothèque qu'on utilise – par exemple si l'upstream ne fait du support que pour la toute dernière version, ce qui est un pratique assez courante dans plein de petits projets. (Ou des fois, la seule raison c'est que le chef le dit!)
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par ZeroHeure (site web personnel) . Évalué à 3.
Oui c'est bien ce qu'on dit, à part les développeurs contraints par de mauvaises raisons, personne…
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Michaël (site web personnel) . Évalué à 1.
Je ne pense pas trop que ce soit à ma distribution de me dire comment je dois travailler ou pas!
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Anthony Jaguenaud . Évalué à 5.
Quand je développe, j’installe les lib de dév. qui ne sont pas dans ma distribution dans mon
/home… pourquoi pourrir mes autres appli qui me servent à être efficace à cause de mon environnement de dev. ?[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Michaël (site web personnel) . Évalué à 1.
C'est une stratégie possible, mais c'est un peu pénible de tout installer et tenir à jour à la main, surtout s'il existe des systèmes qui permettent de tout faire automatiquement.
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par gnumdk (site web personnel) . Évalué à 3.
Peu de raison valables? Et les corrections de bugs qui ne seront jamais intégré dans ta distribution?
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par ZeroHeure (site web personnel) . Évalué à 5. Dernière modification le 11 mai 2015 à 12:31.
Je me cite : [raisons valables] des grosses difficultés dont on espère qu'elles soient résolues
Pour les bugs mineurs, mettre à jour c'est reculer pour mieux sauter parce que tu auras toujours des bugs, même s'ils arrivent sur d'autres applications (vu les changements perpétuels). Au reste tu le sais très bien mon canard, j'ai trouvé des bugs dans tes applis, nul n'y échappe! :-)
Mais évidemment, vous pouvez toujours trouver que votre cas particuliers justifie que … et puis chacun fait comme il veut, etc.
Je vais faire une mauvaise comparaison, mais si des gens — et des entreprises — ont pu bosser sur WinXP si longtemps, c'est bien qu'il n'y a pas tant besoin que ça de mises à jour (au sens changer la version de la distribution) — sauf les exceptions citées plus haut. Et quant aux mises à jour des navigateurs web et des suites bureautiques, c'est beaucoup parce que la course à l'échalotte se poursuit (et que le web est encore très jeune) et à cause, classiquement, du format des fichiers bureautique qui change.
Enfin, n'oublie pas que ça s'accélère sans cesse. Parce que le rythme des changement de version est devenu très élevé : 6 mois, 2 mois, 1 mois, etc. alors que les changements sont assez mineurs. Quelles sont les grosses différences qui justifient de passer immédiatement au nouveau noyau, aux nouvelles versions des applis de KDE-4 ? à la nouvelle version qui tue de Unity ? au nouveau Chrome ou Firefox qui maintenant tu te rends compte mets un pouillème de performance dans la tronche de la version précédente et en plus il ont redessiné les onglets !!!!! c'est d'la balle !!! (dialogue entendu dans la cour de récré) ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par Michaël (site web personnel) . Évalué à 1.
Je ne parle pas ni du noyau, ni d'applications KDE, ni de Unity, qui t'a mis ça en tête?
Dans le logiciel libre il y a plein de communautés différentes, qui ont leurs usages et leurs façons de travailler. Si je veux utiliser le travail d'une communauté et éventuellement l'intégrer et bien oui, la façon de travailler de cette communauté va déteindre sur mon travail, parceque c'est plus facile de s'adapter que de créer une sorte d'interface byzantine entre leur façon de travailler et une autre façon de travailler.
[^] # Re: un truc que je n'arrive pas à comprendre.
Posté par ZeroHeure (site web personnel) . Évalué à 2.
Je répondais à Gnumdk, pas à toi.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Quelques remarques
Posté par Michaël (site web personnel) . Évalué à 6.
Quelques remarques:
Tu ne sauvegardes pas les versions des paquets que tu upgrades, du coup si tu te dis “Aah ben non en fait je préférais celle d'avant…” tu dois chercher la version à la main. En fait ce serait même sûrement mieux de faire une photo des versions installées puis de tout mettre à jour automatiquement.
Tu peux aussi faire
xargs apt-get -y install < packages.Je ne vois ni Emacs ni Vim dans ta liste… fais-tu partie du tiers des français athées? :)
Je ne vois pas
bmakeni BSD Owl Scripts dans ta liste! :)[^] # Re: Quelques remarques
Posté par Marotte ⛧ . Évalué à 2.
Merci pour tes propositions
Je ne comprends pas. Si le package program-2.35 est remplacé par program-2.36 dans la distribution. Comment pourrais-je retrouver le package program-2.35 ? À moins de garder tous les packages que j'installe je ne vois pas comment faire pour permettre ce que tu dis. De toutes façon je n'ai jamais eu le cas où je regrettais une version précédente d'un logiciel… (bien sûr ça pourrait m'arriver un jour…)
Et est-ce mieux ? C'est plus rapide ? Dans le cas de mon script on s'en fout mais je demande par curiosité.
Je prie nano tous les jours qu'Il fait
Je pense pas en avoir l'utilité ! :)
[^] # Re: Quelques remarques
Posté par plietar . Évalué à 3.
Certains shells ont une limite sur la longueur des commandes. xargs sépare en plusieurs invocations de façon à garder un nombre raisonnable d'arguments.
Je ne pense pas que bash ait ce problème, mais c'est plus propre. Par contre c'est plus lent car apt peux être invoqué plusieurs fois, et il prend du temps à charger.
[^] # Re: Quelques remarques
Posté par Michaël (site web personnel) . Évalué à 2.
De mémoire, les paquets restent un certain temps dans les dépôts et il y a de bonnes chances pour que tu puisses reconstruire le paquet à partir des sources.
Moi ça m'est arrivé de temps en temps – ma solution consiste à restaurer un backup du système de fichiers, ce n'est pas très subtil mais c'est très facile, rapide et ça marche bien. :)
Mais si cette situation ne t'arrive pas à quoi bon ne pas tout mettre à jour? Moi, même avec ma connection à 800kB par seconde les jours de fête, ça ne me pose aucun problème.
Il va falloir changer tout ça! :D
[^] # Re: Quelques remarques
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 08 mai 2015 à 22:56.
Et surtout, si tu ne fais pas de 'apt-get clean' à tout va, ton ordinateur conserve lui-même ces paquets en cache (tu peux voir toutes les versions disponibles avec 'apt-cache show tonpaquet'). Du coup, si tu as besoin de revenir en arrière c'est possible jusqu'au prochain 'apt-get clean' que tu fais.
Pour installer une version particulière, je ne connais pas la commande exacte d'apt, j'utilise en général l'interface graphique en ligne de commande d'aptitude pour voir et sélectionner la version qui me convient.
Sinon, pour le téléchargement automatique des paquets à mettre à jour (et éventuellement recevoir un mail qui contient le résumé des màj disponibles), il y a cron-apt (que tu peux configurer pour ne pas mettre à jour automatiquement).
PS: Je viens de voir que ton script faisait directement un 'apt-get clean'. Je pense qu'il serait mieux de mettre cette commande dans une tâche séparée exécutée hebdomadairement ou chaque X jours (que tu aies le temps de voir s'il faut revenir en arrière sur certains paquets).
# Parfois il gèle...
Posté par Yannick . Évalué à 10.
Euh… si. SID est gelée pendant le préparation d'une nouvelle publication.
# demande de précision.
Posté par closed . Évalué à 0.
Bonjour,
Comment tu fais pour obtenir ton fichier packages ?
Merci
[^] # Re: demande de précision.
Posté par Reihar . Évalué à 3.
Je crois que c'est écrit à la main, d'après ce qu'il juge important.
[^] # Re: demande de précision.
Posté par closed . Évalué à 0.
Ok c'est bien ce qui me semblais.
Merci
[^] # Re: demande de précision.
Posté par _eLRIC . Évalué à 1. Dernière modification le 09 mai 2015 à 20:35.
sinon, un petit
peut dépanner
# Rolling release...
Posté par Janfi . Évalué à 3.
J'ai eu longtemps une utilisation similaire de sid, pour l'aspect mise a jour en continu des logiciels.
Globalement cela marchait bien. Le problème, c'est que lorsque debian entre en période de freeze pour sortir la nouvelle stable, terminé c'est bloqué. Et le freeze chez debian, ça peut durer longtemps puisque cela sort quand c'est prêt (et tant mieux).
C'est en partie a cause de cela que j'utilise maintenant fedora même si c'est une distro à release classique, avec toutefois un test en cours d'opensuse tumbleweed (qui est vraiment rolling release) fort convaincant pour le moment (ex : kernel 4, GNOME 3.16, LibreOffice 4.4, FF 37 etc, le tout sans problème à ce jour).
# apt-get clean
Posté par vv222 (site web personnel) . Évalué à 1.
La commande finale 'apt-get clean' va nettoyer complètement le cache des paquets .deb, empêchant de revenir facilement à une version précédente d’un paquet dont la mise-à-jour introduit de nouveaux bugs dont tu te passerais bien. Bien sûr tu peux toujours re-télécharger les anciennes versions… à condition que le bug éventuel n’ait pas fait tomber ta connexion au passage.
Je conseille donc de ne l’utiliser qu’avec prudence (c’est-à-dire pas dans des scripts liés à des tâches cron par exemple).
# Il manque des trucs !
Posté par Sidonie_Tardieu . Évalué à 1. Dernière modification le 15 mai 2015 à 15:46.
Il n'y a pas tout et c'est old-school oriented, mais bon, at ze looch :
abook
arandr
atop
aspell
autojump
awesome
awesome-extras
checkinstall
clipit
curl
devilspie
dish
dmsetup
elinks
enchant
feh
flac
fuse
git
gpick
htop
hyphen-fr
icedove-l10n-fr
iceweasel-l10n-fr
iptraf
keychain
lm-sensors
mc
mediainfo
meld
moc
mosh
mpv
mutt
nethogs
pass
pwgen
python-pip
ranger
rename
ristretto
rxvt-unicode-256color
screen
scrot
sshfs
suckless-tools
thinkfan
tmux
tor
unclutter
vim
w3m
wget
weechat-scripts
x2x
xdotool
xfonts-terminus
xinput
xstow
zim
zsh
Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.