Faire de la place sur son DD

Je cherche à faire de la place sur mon DD, il n’y a pas le feu car après un ‘apt-get clean’, j’arrive à 62% pour ma ‘/’.

Quand j’ai installé cette vieille debian fonctionnelle, je n’avais pas pensé à placer /usr ds une partoche à part et c’est surtout cette dernière qui prend de la place.
Ma question (à laquelle il a déjà été répondu, il me semble mais je ne retrouve pas) :
Peut-on virer les fichiers/dossiers qui sont ds /usr/src, une fois que la compil a été faite ?

[quote=“ricardo”]Peut-on virer les fichiers/dossiers qui sont ds /usr/src, une fois que la compil a été faite ?
[/quote]
Ca ne m’a jamais posé de pbs de le faire ,mais j’ai tjs gardé les sources du noyau , en prévision de futures compils (même si je préfère largement un .deb à une compil,mais des fois on n’a pas le choix…)

Merci Yanlolot.
Votre avis sur ces autres dossiers :
peut-on les vider partiellement voire complètement ?
/lib/modules (pour ce qui concerne les anciens noyaux )
/boot (pour les config, initrd.img, system.map et vmlinuz anciens)
/var/log (lesquels peut-on virer ou vider ? )
/usr/share/locale (utile de conserver ts les dossiers de langues dont on ne se sert pas ? )

Si tu ne te sers plus de tes anciens noyaux, t’as pas de raison de garder ces modules.
Mais un apt-get --purge ton_ancien_noyau te vire tout ça non ? (pareil pour tout ce qui est relatif à ton ancien noyau dans /boot )

[quote=“ricardo”]/var/log (lesquels peut-on virer ou vider ? )[/quote]Sans problème tout ce qui est archivé je pense, au moins les *.n.gz …

Si tu ne te sers plus de tes anciens noyaux, t’as pas de raison de garder ces modules.
Mais un apt-get --purge ton_ancien_noyau te vire tout ça non ? (pareil pour tout ce qui est relatif à ton ancien noyau dans /boot )[/quote]Oui. Dans ce répertoire, si on gère sa debian proprement, on ne doit pas à toucher soi même à quoi que ce soit.

[quote=“yanlolot”][quote=“ricardo”]Peut-on virer les fichiers/dossiers qui sont ds /usr/src, une fois que la compil a été faite ?
[/quote]
Ca ne m’a jamais posé de pbs de le faire ,mais j’ai tjs gardé les sources du noyau , en prévision de futures compils (même si je préfère largement un .deb à une compil,mais des fois on n’a pas le choix…)[/quote]On peut effectivement avoir besoin des sources du noyau qu’on utilise, et on peut normalement faire un make-kpkg clean pour le reduire en taille, mais si on ne pense pas avoir besoin de compiler un module avant longtemps, on peut carrément virer l’arbo (la config restant dispo dans /boot, on peut recompiler à l’identique quand on veut).

Sinon, peut être un peu de place à trouver en vidant complètement /tmp (en monoutilisateur, et pas sous Xwindows).
Rien à récupèrer dans /usr.
Si tu veux supprimmer des logs pas encore compressés (evite de supprimer le log d’aptitude), il vaut mieux les vider que les supprimmer, certaines applis bloquant si les logs ne sont pas là, et d’autre ne les recréant pas si on les supprime.
Finalement, un apt-cache clean peut aussi vider un peu le cache des paquets.

apt-get autoclean tu veux dire non ? parce que apt-get clean ça le vide pas qu’un peu je crois :smiley:

peut être. A voir dans le man.

Merci à ts de vos réponses et ne vs gênez pas pour continuer si vs avez d’autres idées de “faisage de place” comme dirait mon fils.
J’en ferai une synthèse et un tuto ds T&A.

Oui … par exemple j’ai 1.5Go dans /var/cache/apt, malgré mes autoclean … je trouve que ça fait beaucoup.

Il y a la possibilité aussi de purger les paquets inutiles avec deborphan (gtkorphan ) ou debfoster. Mais si ta machine est chargée en softs, 1.5Go c’est pas anormal.

Oui elle est chargée comme une mule :smiley:

oui clean est plus approprié pour nettoyer dans le cache :
la différence entre les deux dans le man.

[quote]clean
La commande clean nettoie le référentiel local des paquets
récupérés. Il supprime tout, excepté le fichier lock situé dans
/var/cache/apt/archives/ et /var/cache/apt/archives/partial/[/quote]

[quote]autoclean
Tout comme clean, autoclean nettoie le référentiel local des paquets
récupérés. La différence est qu’il supprime uniquement les paquets
qui ne peuvent plus être téléchargés et qui sont grandement
inutiles. On peut ainsi contrôler la taille de ce cache sur une
longue période. Tant qu’elle n’est pas activée, l’option de
configuration APT::Clean-Installed empêche la suppression de paquets
installés.[/quote]

Ouai ben ça fait dix fois que je lis la dernière phrase de ta citation sur la directive clean-installed, et ça fait 10 que ça me paraît du petit chinois lol …

ps: pas tant chargée que ça :

dpkg -l | grep ii | wc -l 1711 ça fait que 877 Ko de moyenne par soft/librairie…

[quote=“mattotop”]Il y a la possibilité aussi de purger les paquets inutiles avec deborphan (gtkorphan ) ou debfoster. Mais si ta machine est chargée en softs, 1.5Go c’est pas anormal.[/quote]Oui pour gtkorphan mais il faut le manier avec précautions car je crois qu’il ne fait pas bien le tri de ce qui est à jetet et il ya eu des surprises, à ce qu’il paraît.
Plus de précisions sur son emploi avec sécurité serait bienvenu.

Si tu ne te sers plus de tes anciens noyaux, t’as pas de raison de garder ces modules.
Mais un apt-get --purge ton_ancien_noyau te vire tout ça non ? (pareil pour tout ce qui est relatif à ton ancien noyau dans /boot )[/quote]
À partir d’où tu lances cette commande et concrêtement, que met-on à la place de “ancien_noyau” :question:

Ben c’est surtout qu’il te propose de supprimer les paquets ne dépendent d’aucun autre, mais ça ne veut pas dire, même s’ils ne sont pas indispensables, qu’il soient inutiles. Par exemple, les paquets genre libwine-alsa ou un truc comme ça qui fournit du son alsa dans wine ne sont pas necessaires au fonctionnement. Et pas mal de codecs audio sont sous forme de libs.
Donc, c’est impossible de faire une doc “générale” sur ce que tu peux supprimer ou pas avec deborphan. Quand tu ne sais pas, tu laisses.
Deborphan permet juste de choisir parmi les orphelins si tu en vois à supprimmer.

d’accord, donc on peut le considérer comme une indication, le choix restant quand m^ sous ta responsabilité.