Ricardo Igarashi <[EMAIL PROTECTED]> writes:
> Eu sei :) Eu n�o estou criticando a Conectiva por essa mudan�a.
> O esquema anterior tamb�m tinha os seus problemas.
:-)
Muito mais problemas do que hoje, creio eu.
>> 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.
Sim, mas voc� ter� que explicitamente instalar esses outros
pacotes. IMHO, conviver com algumas coisas que n�o uso da glibc �
toler�vel (glibc-prof, por exemplo) enquanto que conviver com a vers�o
em mandarim n�o � necess�rio.
Essa sugest�o permitiria isso.
> 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.
IIRC, � assim. S� que esse pacote chama-se "glibc-base". S� que, como
voc� disse, n�o tem o nome de pacote "glibc".
> 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.
:-)
(Lembrando daquela hist�ria de preocupar-se com a distribui��o...)
Bem, o Apt � a ferramenta oficial para uso com o CL 6.0 e CL
7.0... Como estamos falando do CL, n�o vejo problema nenhum em fazer
isso, exceto para os pobres empacotadores descobrirem exatamente quais
arquivos s�o necess�rios para cada um dos 1500+ pacotes.
Ia ser um inferno dar manuten��o nisso. E, acredite, voc� nunca ia ter
as depend�ncias para constru��o do pacote corretas.
> Convenhamos: n�o ter instalado os pacotes "glibc" e "XFree86" (que
> � o meu caso) n�o faz bem para o cora��o ;)
Meu caso tamb�m. :-)
>> 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 ;)
Ela funciona... ;-) E engana bem.
N�o sei se � 'Dirty'. Acho que n�o.
>> 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.
A vers�o � 0.8.8 ou 0.88? Se for a primeira, todo mundo est�
errado... :o) Se for a segunda, realmente � um bug (erro de digita��o
no SPEC?).
Quanto a usar o bugzilla, t� desacostumando a navegar? :-)
> 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...
Cadastre um usu�rio, depois na p�gina principal, clique em verificar
bugs j� cadastrados, preencha o n�mero de campos que achar relevantes
para encontrar o problema (no teu caso, provavelmente, seria apenas o
de pacote), escolha os status dos bugs que desejas verificar (no teu
caso todos deveriam estar selecionados) e clique no bot�o de
submiss�o. :-)
Acho que h� instru��es mais detalhadas no site do Mozilla...
E acho que poderiam haver instru��es no site da Conectiva.
Se eu tiver um tempinho, escreverei direito. (E n�o a lamban�a de dois
par�grafos acima :o))
> 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.
O RPM (ainda?) n�o tem suporte para isso. Ou o pacote � necess�rio ou
n�o �. O DEB tem suporte a "recommends".
Isso � algo que sempre comentamos e todo mundo acha que deveria
ter. :-)
> Mas o LSB n�o chega a esse ponto, e _acho_ que nem deveria.
Acho que chega ao ponto de normatizar nomes de pacotes b�sicos
sim. Eles t�m especifica��es de m�quinas de desenvolvimento, por
exemplo.
> 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 :(
Isso teria que ser uma iniciativa dos usu�rios. As distribui��es, como
eu disse, t�m que se preocupar com seus pr�prios pacotes. Acredite em
mim que manter aquelas coisas funcionando � dif�cil. S�o muitas
atualiza��es, s�o muitas depend�ncias, s�o muitos pacotes.
Voc� que tem o Apt, instale o graphviz em tua m�quina e gere um mapa
de depend�ncias. Veja a quantidade de linhas negras que est�o ali. :-)
Compare a sa�da de um mapa desses do 6.0 com um do 7.0... As coisas
melhoraram significativamente, mas ainda temos muito o que
melhorar. H� pessoas preocupadas exclusivamente em definir como isso
ser� feito (fica tranq�ilo -- ou n�o -- que s�o engenheiros el�tricos
tamb�m :o)).
> 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
Podes, tamb�m, escrever um SPEC e coloc�-lo num futuro contrib que
est� para surgir.
> 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.
N�o sei se h� esse interesse por parte de todos os que usam RPM. Mas,
a id�ia � v�lida. Infelizmente, eu n�o sou a pessoa que tem que fazer
isso. Espero que o ACME (Arnaldo) esteja lendo.
> E talvez um novo formato para o RPM.
O novo formato � discutido na lista de desenvolvimento do RPM... :-) A
Conectiva participa.
>> 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...
J� dizia Linus Torvalds: "Queremos dominar o mundo. N�o precisa ser
hoje ou amanh�, pode ser semana que vem".
Voc� espera que, tendo o mestre essa paci�ncia toda para a domina��o
global, as pessoas preocupem-se com os nomes de pacotes logo de cara
no LSB? :-)))
Eu concordo que vai demorar, mas as discuss�es nesse sentido j�
aconteceram antes de sair a vers�o 1.0 do LSB. N�o sei se demora muito
mais... Vamos ver.
--
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 13/09/2001: 2366
Mensagens recebidas desde 07/01/1999: 132081
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
