Puis-je désactiver toutes les pages de manuel?


14

Plus précisément sur un Raspberry Pi (exécutant Raspbian Wheezy), mais aussi en général, puis-je désactiver toutes les pages de manuel?

Cela signifierait aucune page de manuel stockée, aucun "déclencheur de traitement pour man-db", etc. Les pages de manuel étant toujours disponibles sur Internet, je n'ai pas vraiment besoin qu'elles soient installées, et les générer et les stocker semble inutile.


Je crains que vous ne soyez probablement bloqué en ce qui concerne les pages de manuel elles-mêmes - elles font partie des debs du logiciel avec lequel elles vont.
Shadur

6
Il y a sûrement de meilleurs candidats pour économiser de l'espace que les pages de manuel?
jasonwryan

Je pourrais imaginer une configuration d'un outil de conditionnement pour supprimer tous les fichiers marqués comme documents et / ou fichiers correspondant à une expression régulière. Je ne suis cependant pas au courant des implémentations de ce concept.
Pavel Šimerda

Vous ne feriez qu'économiser, quoi, 1% d'espace (probablement moins en fait)? Probablement un peu plus si vous supprimez également /usr/share/doc.
Gilles 'SO- arrête d'être méchant'

Réponses:


16

J'avais le problème opposé sur une image Debian 8 que quelqu'un avait mise en place pour un Wandboard. J'essayais de trouver la page de manuel pour certains paquets qui étaient déjà installés et j'ai remarqué qu'après en avoir installé de nouveaux, les pages de manuel manquaient, même si elles étaient présentes dans le fichier deb.

J'ai ensuite trouvé ce fichier 01_nodoc dans /etc/dpkg/dpkg.conf.d, qui est une solution simple à la question d'origine sur la façon d'économiser de l'espace en supprimant les pages de manuel et les fichiers locaux et de copyright où l'espace est à une prime (par exemple intégré systèmes).

# /etc/dpkg/dpkg.conf.d/01_nodoc

# Delete locales
path-exclude=/usr/share/locale/*

# Delete man pages
path-exclude=/usr/share/man/*

# Delete docs
path-exclude=/usr/share/doc/*
path-include=/usr/share/doc/*/copyright

Une autre réponse utile à askubuntu.com/a/401144/162384 , qui - en plus d'un excellent exemple - des points aux docs: wiki.ubuntu.com/ReducingDiskFootprint#Documentation
Berto

6

Le problème est que le système de gestion des packages s'attend à ce que les fichiers qu'il installe (y compris les pages de manuel) y restent, donc quel que soit le mécanisme que vous utilisez pour les supprimer (sauf la reconstruction de chaque package comme le suggère HalosGhost) va le confondre.

Si ce que vous faites est de produire une appliance à usage unique, vous pouvez adopter une approche distincte pour la création et le déploiement de l'appliance. Autrement dit, vous installez tous les packages souhaités dans un environnement de génération distinct (une carte SD différente ou un RPi émulé), puis copiez uniquement ce que vous voulez avoir en production de l'environnement de génération vers l'environnement de production. À ce stade, vous pouvez laisser de côté les pages de manuel et tout ce qui n'est pas nécessaire en production.

Afin de récupérer le système d'exploitation mis à niveau ou les correctifs de sécurité, vous mettez à niveau ou reconstruisez l'environnement de génération et copiez (ou rsync) à nouveau en production.

C'est un peu plus de travail, mais cela vous donne un appareil de production très contrôlé, comparé à la connexion et à l'exécution de mises à niveau directement dessus.


5

Eh bien, ne sachant pas quelle distribution votre RPi exécute, je ne peux pas vous aider avec les commandes exactes, mais vous pouvez probablement supprimer le man-dbpackage qui fournit à la fois l' manutilitaire et une variété de pages de manuel. Cependant, la suppression de toutes les pages de manuel nécessiterait la suppression de chaque page de manuel de chaque package. Je ne peux pas imaginer que cela vaille la peine de gagner du temps simplement pour économiser des Ko d'espace.

Si vous le vouliez vraiment, alors vous auriez besoin de reconstruire chaque paquet; sur une distro comme Archlinux ou Gentoo, ce n'est pas forcément impossible, mais reste assez fastidieux. Sur d'autres distributions moins «pratiques», vous pouvez trouver cette tâche incroyablement difficile.


2
apt-get remove --purge man-dbdésinstallera également debhelpern'est-ce pas nécessaire?
rubo77

4
$ cat /etc/apt/apt.conf.d/90debsums 
DPkg::Post-Invoke { "if [ -x /usr/bin/debsums ]; then /usr/bin/debsums --generate=nocheck -sp /var/cache/apt/archives; fi"; };

Le package debsumsinstalle une action pour générer automatiquement des listes md5sum pour les packages après l'installation d'un package sans avoir déjà son propre fichier md5sums.

Vous pouvez ajouter une action de post-installation similaire en analysant et en supprimant les pages de manuel (et les documents d'information) après chaque action d'installation.

Pour obtenir les pages de manuel et les packages propriétaires, vous devez parcourir tous les /var/lib/dpkg/info/PACKAGENAME.listfichiers.

Vous devez également mettre à jour les *.listfichiers pour ne plus mentionner les pages de manuel supprimées.

localepurgefait partiellement cela aussi. Extrait de apt-cache show localepurge:

Il s'agit d'un script pour récupérer l'espace disque gaspillé pour les paramètres régionaux inutiles, les localisations Gnome / KDE et les pages de manuel localisées. Selon l'installation, il est possible d'économiser environ 200, 300, voire plus de méga octets d'espace disque dédié à la localisation dont vous n'aurez probablement jamais besoin. Il s'exécute automatiquement à la fin de toute action d'installation appropriée.

La citation la plus importante:

Veuillez vous abstenir de signaler de tels bogues blâmant localepurge si vous cassez votre système en l'utilisant. Si vous ne savez pas ce que vous faites et que vous ne pouvez pas gérer vous-même les bris qui en résultent, veuillez simplement ne pas utiliser ce package.

;-RÉ

Faites donc une sauvegarde complète et essayez d'écrire votre manpagekiller...


1
C'est aussi la solution que j'avais en tête (ça, plus ne l'installe pas man-db). J'ajouterais le hook post-invocation via /etc/dpkg.cfg.dplutôt que via APT, pour gérer les invocations directes de dpkg.
Gilles 'SO- arrête d'être méchant'

Bien! En tant .debqu'action par package (par ), dpkgil sera même plus facile que l'action de post-installation aptcar vous aurez le nom du package et vous n'aurez pas besoin d'analyser tous les *.listfichiers pour les pages de manuel encore et encore. J'ai juste oublié que ça dpkga aussi un crochet ...

Hmmm ... mais la gestion des packages installés plus tôt que ce gestionnaire nécessitera toujours l'analyse des *.listfichiers. Néanmoins, le dpkgcrochet post-invocation est le meilleur endroit pour déclencher cette action.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.