On Wed, 12 Sep 2001 08:51:30 -0300
Jorge Godoy <[EMAIL PROTECTED]> wrote:
> > 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 :-(
Eu sei :) Eu n�o estou criticando a Conectiva por essa mudan�a.
O esquema anterior tamb�m tinha os seus problemas.
> 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.
Isso s� resolve em parte, pois _pode_ haver outros pacotes n�o
necess�rios.
Uma id�ia seria fazer o pacote "glibc" apenas com os arquivos realmente
necess�rios para o funcionamento do sistema (apenas com o idioma "C",
eu acho). E n�o se se isso poderia quebrar depend�ncias.
Creio que o ideal seria ter depend�ncia somente de arquivos, e n�o de
pacotes. Como defeito, fica dif�cil descobrir qual o pacote necess�rio
se voc� n�o est� usando o apt.
Convenhamos: n�o ter instalado os pacotes "glibc" e "XFree86" (que
� o meu caso) n�o faz bem para o cora��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.
Humm, uma solu��o Quick & Dirty ;)
> > 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... :-(
:)
Ali�s, o pacote xforms do CL7.0 est� com numera��o "errada":
todo mundo usa 0.88, e a Coenctiva est� usando "0.8.8".
Pensei em colocar no Bugzilla, mas n�o entendi como us�-lo :P
Nesse caso, editei o spec do aplicativo (LyX) na m�o.
> 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.
Se me permite: o bugzilla � uma zona! Tentei descobrir se o "bug"
acima j� estava cadastrado, e n�o consegui descobrir como faser
isso :(
Um helpzinho ajudaria...
> > O esquema de depend�ncia atual est� ficando ultrapassado?
>
> Esse � *outro* problema. :-)
Minha opini�o/sugest�o: incluir pacotes "recomendados".
Por exemplo: o WindowMaker exige o pacote "background". Mas,
convenhamos, ele n�o precisa dele para rodar, embora fique
melhor com ele e talvez a instala��o padr�o o use.
Nesse caso, um "recomenda" seria melhor.
Idem para os idiomas no Glibc.
> 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.
Mas o LSB n�o chega a esse ponto, e _acho_ que nem deveria.
Uma coisa que poderia ser interessante: um "configure" para o
arquivo spec. Voc� roda o "configspec", e ele checaria qual os
pacotes necess�rios para a sua distribui��o. Depois, bastaria
criar o pacote bin�rio e instalar no sistema.
� claro que � complicado padronizar isso :(
> 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.
O problema � que eu|voc�|ele|ela|pai|filho|"esp�rito santo" posso
querer instalar um pacote que s� � interessante para poucas
pessoas. O pacote libjconv que coloquei no exemplo anterior �
para tratamento de japon�s. E qur usar o CL7.0 :)
Claro que posso instalar com "make install", mas � chato :P
> 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...)
Na verdade, deveria trocar id�ias com RH, SUSE, Caldera, Mandrake,
Vine, Kondara etc etc etc que usam o pacote RPM, para tentar
padronizar pelo menos a "estrat�gia" para a cria��o de pacotes.
E talvez um novo formato para o RPM.
> > 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.
Hahaha.
> A outra solu��o seria que
> todos empacotassem como a distribui��o projeta seus pacotes. Mais
> ut�pica ainda.
Hahaha.
> A terceira seria ter um padr�o "universal" de
> pacotes. Essa � mais real e deve surgir com o LSB.
Pelo que vejo do LSB, isso n�o vai acontecer. Pelo menos n�o
nas primeiras vers�es...
--
Ricardo Yassuo Igarashi
E-mail: [EMAIL PROTECTED]
Linux HP: http://web.that.com.br/iga
Assinantes em 13/09/2001: 2366
Mensagens recebidas desde 07/01/1999: 132071
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
