[ Apesar de estar em todas as minhas mensagens, para essa vale a pena
frisar: esta � *MINHA* opini�o e pode divergir da opini�o da
Conectiva ]
Ricardo Igarashi <[EMAIL PROTECTED]> writes:
> erro: falha nas depend�ncias:
> glibc >= 2.1.0 � necess�rio para libjconv-2.7-1vl3
>
> Bom, o CL7.0 usa o glibc-2.2.3, que atende � especifica��o.
> S� que eu n�o tenho o "pacote" glibc-2.2.3 instalado, pois ele
> depende de um monte de m�dulos i18n. Afinal, foi para isso
> que o glibc foi picotado, certo?
Esse foi um exemplo ruim :-(
Voc� est� certo no motivo e est� certo no problema. Eu tenho a mesma
discuss�o com o pessoal aqui... Acho que a solu��o seria fazer com que
a glibc fosse um metapacote para os idiomas pt_BR, en_US e es_ES
apenas, n�o para todos. Poder�amos ter um task-glibc que instalasse
todos. Assim, poder�amos ser backward compatible sem perder 48MB de
espa�o com idiomas que nunca usaremos.
J� comentei isso e a resposta que obtive, naquela ocasi�o, foi a de
facilitar para o desenvolvedor ou usu�rio em outro idioma (alem�o, por
exemplo). Penso que eles sabem ler ingl�s e podem procurar na
documenta��o como instalar a internacionaliza��o para seu idioma, j�
que a Am�rica Latina � o foco que a Conectiva tem "hoje" (apesar de
ser usada na Alemanha, v�rios pa�ses da Europa, Jap�o....).
Outra sugest�o, era todas as glibc-i18n-.... terem um "Provides:
glibc". Ter�amos m�ltiplos pacotes com esta caracter�stica instalados
simultaneamente, mas n�o perder�amos os 48MB de disco quando
quis�ssemos instalar algo e j� tiv�ssemos suporte ao nosso idioma ali
presente.
> Bom.... e a�? Preciso instalar o pacot�o? N�o uso o pacote? :P
> Ou edito o .spec dele para tirar a depend�ncia?
O que eu tenho feito, quando poss�vel, � editar o SPEC... :-(
Sugiro que voc� fa�a um bug report (se quiser pode colar minhas
sugest�es nele) no nosso bugzilla e pergunte QUAL � a sa�da
recomendada para usu�rios leigos em uma m�quina com espa�o em disco
relativamente curto, em uma m�quina com recursos de mem�ria
relativamente curtos, e em outras m�quinas que puderes imaginar. De
minha parte, eu N�O gosto da atual solu��o: instalar tudo.
> O esquema de depend�ncia atual est� ficando ultrapassado?
Esse � *outro* problema. :-)
IMHO, uma distribui��o deve preocupar-se apenas com os pacotes
mantidos por ela. Esse pacote n�o Conectiva, por exemplo, "n�o �
problema nosso". S� que isso � algo extremamente radical. O que
acontece? Preocupa-se em manter um padr�o (acho que o LSB tentou falar
sobre isso, mas n�o sei se entrou na vers�o 1.0 das especifica��es) e
espera-se que as pessoas ao redor do mundo o sigam tamb�m.
Caso muitas pessoas precisem de algo, ou algu�m importante (geralmente
falando de forma financeira, pois � desses "algu�ns" que as empresas
de Linux sobrevivem) precise, ou ainda algum desenvolvedor esteja de
bom humor e ache o software que voc� viu legal e queira mant�-lo, ele
*pode* vir a ser inclu�do na distribui��o. A� ele passa a ser
compatibilizado com os pacotes dela.
N�o sei se a Conectiva j� liberou guidelines para a montagem de
pacotes. Se n�o liberou, seria interessante t�-las. (N�o sei se
liberou pois temos normas internas, mas acho que n�o formalmente
escritas...)
> Qual seria a solu��o?
A solu��o seria a distribui��o ser respons�vel por empacotar, para
voc�, aquilo que voc� precisa. � ut�pica. A outra solu��o seria que
todos empacotassem como a distribui��o projeta seus pacotes. Mais
ut�pica ainda. A terceira seria ter um padr�o "universal" de
pacotes. Essa � mais real e deve surgir com o LSB.
Vamos esperar pra ver. ;-)
Abra�os,
--
Godoy. <[EMAIL PROTECTED]>
Solutions Developer - Conectiva Inc. - http://en.conectiva.com
Desenvolvedor de Solu��es - Conectiva S.A. - http://www.conectiva.com.br
Assinantes em 12/09/2001: 2359
Mensagens recebidas desde 07/01/1999: 131931
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
