Christian Gennerat wrote:
>
> Je reprends ici des �l�ments d'un pr�c�dent envoi:
>
> La taille occup�e par /usr est excessive!
> Diverses actions doivent �tre men�es:
>
> 1- N'installer que ce qui est utile, selon la configuration. Quelques exemples:
>
> /usr/share/terminfo contient 2090 fichiers.
> Un utilisateur courant n'en utilise pas plus de 5:
> linux, linux-lat, xterm, xterm-color, vt100.
> Il faudrait faire la s�lection lors de l'installation de l'archive rpm.
>
> /usr/share/zoneinfo contient 507 fichiers.
> Un utilisateur s�dentaire n'en utilise qu'un!
>
> /usr/share/i18n contient 180 charmaps.
>
> /usr/share/locale contient des fichiers pour toutes les langues.
> Ce n'est pas utile. L'utilisateur a d�j� indiqu� lors de l'installation
> quelle est sa langue; on pourrait lui demander ses pr�f�rences pour la
> localisation, par exemple, avec � fr;en;es �, on installe la localisation
> � fr � si elle existe, sinon, et si la langue d'origine du paquet n'est
> pas � en �, la localisation � en �, sinon la localisation � es �
> si elle existe; sinon rien. La localisation � ru � ou � pl � ne sert
> � rien � un utilisateur qui ne comprend pas cette langue.
> Certaines localisations sont plac�es dans /usr/lib
> (par exemple /usr/lib/linuxconf)
>
> Pour r�sumer, utiliser des archives rpm compl�tes, mais un utilitaire
> d'installation-configuration qui extrait les fichiers utiles en fonction
> des pr�f�rences d�clar�es par l'utilisateur.
C'est ben vrai �a!
d'une mani�re g�n�rale, les distribs sont de venues de plus en plus
monstrueuses un petit r�gime ne leur ferait pas de mal !
> 2- Un moyen simple de faire une installation all�g�e consiste � supprimer
> la documentation. Mais celle-ci est �parpill�e:
> D'abord dans les r�pertoires d�di�s: �/usr/doc � �/usr/info � �/usr/man �
> Mais aussi dans �/usr/lib �, on trouve des sous-r�pertoires �html �, �doc �,
> �examples �, �test �, � help�, � help.eng �, � demos �, � manual �,
> � tutorial �. Tous ces r�pertoires devraient �tre harmonis�s et mut�s dans
> � usr/doc �.
> � usr/lib � doit �tre r�serv� � ce qui est n�cessaire au fonctionnement
> du programme.
> Dans la plupart des cas, avoir la doc disponible sur CD suffirait
> et �conomiserait beaucoup de place.
J'en revien au management des rpms,
il serait pratique de voir les �l�ments install�s sous forme
arborescente
au sein d'un m�me package, et de pouvoir '�laguer un peu'
(au risques et p�rils de l'utilisateur car je pense qu'un tel niveau de
gestion de d�pendances
et difficile � atteindre, mais on a rien sans rien !)
et faire alors apparaitre les parties manquantes en gris�.
Il serait alors beaucoup plus facile de d�gager � la mano
la doc ou les exemples de tel ou tel programme.
il est m�me envasageable de stocker des infos sur ces branches
dans le rpm, sous forme d'un fichier 'mandrakerpm.txt'ce qui
conserverait une compatibilit�
avec les rpms red hat, tout en proposant des options d'install sous
mandrake
genre des pages de cases � cocher r�cursives type install MSoffice
permettant
de se mitonner une installation personnalis�e au mieux.
> 3- La documentation, (pour ceux qui ont de la place) est h�t�roclite.
> Plusieurs formats co-existent: man, html, howto, ps, info, et autres.
> La encore, on pourrait demander les pr�f�rences de l'utilisateur, et
> convertir lors de l'installation les documents dans le format pr�f�r�,
> en �vitant les redondances.
>
> 4- Le choix des outils. Actuellement un utilisateur ne peut pas choisir
> les langages et outils utilis�s: un utilisateur qui dit (ou pense)
> � le python ne m'int�resse pas, je ne veux pas l'installer �
> installe quand m�me python parce qu'il est requis par des outils de
> configuration. Et c'est ainsi qu'on se retrouve avec des tas d'outils
> et de paquets dont on a pas vraiment besoin et qui font � peu pr�s la
> m�me chose. On ne contr�le pas plus ce qu'on met dans sa machine,
> qu'avec d'autres O$ o� on ne sait pas du tout ce quels programmes
> contient la machine. Bref, ne pas confondre avec Windo$
c'est bien le probl�me de linux, �a part dans toutes les directions,
le grand nombre d'outils redondant est � la fois une force et une
faiblesse,
il serait bon de faire des choix au risque d'en faire hurler certains,
perso je trouve tr�s p�nible la coexistance de kde et gnome
(y'a qu'a lancer gnomba sous kde pour cr�er un bordel monstre sur le
bureau !)
et j'esp�re que l'un des deux va mourrir tr�s vite ou qu'une 'fusion'
sera possible, je ne suis partisant ni de l'un ni de l'autre,
mais il faut converger vers un standard simple et l�ger,
enfin bon, l� on sort un peu des possibilit�s d'interactions de
Mandrake.
Seb
