Le mardi 08 mars 2005 � 09:45 +0100, Sophie Gautier a �crit :

Bonjour Sophie,

> > En effet j'ai effac� les RPMs qui ne me concernaient pas.
> > Mais ce n'est pas tellement "user-friendly", non ?
> 
> Ce n'est pas une version utilisateurs :)

Certes, mais alors la question qui tue : comment ce probl�me sera-t-il
r�solu pour la 2.0 finale ? On ne peut raisonnablement s'attendre � ce
qu'il y ait des rpms pour chaque syst�me de menu Linux diff�rent. Il
faut donc faire un choix. j'avais compris que ce choix s'�tait fix� sur
les menu Suse pour la large population d'utilisateurs allemands
(historiques) de StarOffice/OpenOffice sous Linux Suse, et pour RedHat
pour les autres, car c'est bien cette distribution qui serait la plus
install�e au monde actuellement. Soit, mais cela oblige donc � les
laisser dans le tarball.

Personnellement, la strat�gie du RPM peut avoir ses m�rites si elle est
bien conduite. J'entends par l� que les RPMS doivent pouvoir �tre
t�l�chargeables ind�pendamment les uns des autres que les d�pendances
soient r�solues. Aujourd'hui, nous avons 8 RPM dits "core", ensuite les
modules, les filtres XSLT, le module java, et un RPM pour chaque module
de la suite proprement parl�, plus ceux pour les menus RedHat et Suse.
Si on veut pouvoir utiliser les RPMs comme il se doit, il devrait �tre
possible de faire une installation morcel�e sachant que qq soit le RPM
choisi, les d�pendances seront r�solues. Je n'ai pas l'impression que ce
soit le cas aujourd'hui. Si on essaie d'installer un module Impress par
exemple, on te r�pond avec un message d'erreur comme quoi core-06 est
n�cessaire (je ne me rappelle plus du num�ro exacte), mais le paquetage
n'est pas con�u pour aller r�gler cette d�pendance de lui-m�me, m�me si
le fichier en question se trouve dans le m�me r�pertoire. En gros, cela
ne me fait pas gagner du temps.

L'avantage de l'ancien syst�me �tait que tout �tait installable
avec ./install ou ./setup (�ventuellement avec l'option -net). L'admin
tapait au plus deux mots. Aujourd'hui, il doit saisir rpm openoffice-*,
et encore penser � supprimer les paquets Suse ou Redhat avant si son
syst�me n'est pas un de ceux retenus. J'ajoute qu'en outre, si l'admin
veut choisir son r�pertoire d'installation, il est oblig� de l'ajouter
manuellement avec l'option --prefix=/endroit/ou/je/veux/installer, alors
que pr�c�demment la question lui �tait pos� par le biais d'une interface
graphique. Pour moi, tout ceci est un tr�s grand pas en arri�re au
niveau du "Usability".

Les distributeurs Linux actuels ont tendance � s�parer l'ensemble de la
suite en 3 paquets RPM : le coeur de l'appli, les biblioth�ques, et puis
le module de langue, mais l'installation dans ce cas int�gre mieux la
suite dans le syst�me (/etc,/usr/lib,/usr/share), int�gration dans Gnome
et KDE et les menus d'autres WM, donc plus int�gr� qu'avec le OOo natif.
Cela rend l'installation et la d�sinstallation de ces paquets un jeu
d'enfant. Evidemment, ces paquets sont sp�cifiques � la distrib que l'on
utilise. Cela me fait donc douter de l'utilit� pour la Communaut� de
fournir des paquets RPM qui n'atteindront pas ce degr� d'int�gration
(car trop disperse, trop de distribs). En r�sumant, pour moi, on a
choisi un syst�me d'installation qui se veut �tre plus facile, sans en
offrir le choix � l'utilisateur de mani�re plus facile, et sans
permettre cette int�gration pouss�e. Cela ressemble fort � un certain
nombre de choix fait dans l'�mulation des fonctions et apparence de la
suite de la concurrence, au d�triment des possibilit�s plus �tendues qui
existent avec la version actuelle. Je ne suis pas le premier � l'avoir
remarqu�, et je pense tr�s sinc�rement que cela va jouer contre nous
dans le long terme.

�videmment, j'ai toujours le loisir de rester avec la version actuelle,
voir la 1.1.5 (si jamais elle voit le jour ;-)), et � l'heure actuelle
c'est sans doute ce que je ferai. J'aime cette flexibilit�, je ne veux
pas la perdre.


Alex





  


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Répondre à