Cristiano Sina wrote:
Oba!!! Romanos!!!!!!!!!!! 8-)
(agora estou lendo Asterix...)
> Cristiano Sina wrote:
>
> >> VIVA A PADRONIZA��O DE PACOTES DE INSTALA��O!
>
> >A grande quest�o ent�o se torna:
>
> >"Vamos nivelar por cima ou por baixo?"
>
> A grande quest�o Lisias, no meu ponto de vista �: Vamos ter um padr�o de
> pacotes de instala��o e acabar com essa mistureba em que as distros se
> encontram hoje!
A� � que t�...
Pra mim tanto faz a distro usar .deb, .rpm, encap ou SlackPack. O que
mata � a granularidade dos pacotes. E isto a LSB n�o padroniza!!!
O que adianta todo mundo usar .rpm, se cada distro granulariza os
arquivos de forma diferente?
Por exemplo, a Conectiva est� granularizando a CL tendendo ao m�nimo, de
forma � diminuir o tamanho dos downloads na hora das corre��es,
praticamente botando cada biblioteca do XFree (por exemplo) num
rpmzinho. Por outro lado, outra distro (chamarei de Lazy Linux) poderia
aumentar a granularidade, colocando todas as libs do XFree num rpmz�o
s�.
Separar as bibliotecas de runtime das de development � um ainda mais um
exemplo de como a Conectiva trabalha esta granularidade.
Agora chega eu, developer wannabe, e digo "Beleza!!! A lsb padronizou o
packman (meu acr�nimo para Package Manager) pro rpm. N�o tenho que me
preocupar com .deb ou Slack n�o sei qu�".
Terei errado? Sem d�vida.
Porque ainda vou ter que fazer dois rpms diferentes, uma pra conectiva e
outra praquela distro Lazy... Continuo tendo que montar dois pacotes,
cada um com depend�ncias diferentes...
Falando s�rio, faz tanta diferen�a um mero detalhe da sintaxe do .spec
do packman? Ainda mais porque est�o saindo automatizadores deste
processo, que num futuro pr�ximo abstrair�o as diferen�as destes
sistemas de pacotes (se � que j� n�o o fazem hoje!)...
> >Porque se vamos nivelar por cima, crriaremos complica��es excessivas
> >para muita distro de pequeno e m�dio porte. Se vamos nivelar por baixo,
> >criaremos complica��es excessivas para as distros de grande porte.
>
> Eu acho que n�o existem complica��es maiores em se adotar uma padroniza��o!
> Ora, creio que a n�o padroniza��o entre as distro recentes e futuras � que
> implicar� numa complica��o exceciva!
A� � que t�... T�o padronizando algo facilmente abstra�vel por software
(a camada de pacotes), e deixando ao Deus dar� a granularidade dos
pacotes...
Esta padroniza��o, ao menos num futuro pr�ximo, n�o traz benef�cio
nenhum, exceto na sintaxe do montador de pacotes...
Okey, est�o sendo definidos os tais pacotes lsb*.rpm. Mas eles n�o
definem uma distro inteira. At� porque se definissem, se nivelaria tudo
e todas as distros seriam iguais, mudando somente a apar�ncia (bem
estilo Redmond Linux).
> Seria muito mais simples e porque n�o dizer mais acess�vel um linux
> padronizado em termos de pacotes de instala��o, sinceramente vejo muito mais
> futuro para p SO se isso acabar se concretizando!
A padroniza��o que vc defende se restringe � sintaxe da linha de comando
e ao formato do banco de dados de pacotes.
As depend�ncias n�o est�o sendo padronizadas. At� porque n�o existe um
consenso sobre qual a granularidade adequada. Tem muita gente malhando a
Conectiva pelo esquema de granularidade dos pacotes dela, mas tamb�m tem
muita gente elogiando!!
> >Fica-se entre a cruz e a espada : ou tira-se os pequenos e m�dios da
> >parada (justamente o modelo Microsoft de fazer b�uziniss) ou aumenta-se
> >o custo de manuten��o das grandes.
>
> Novamente descordo, n�o acho necess�rio nada disto, apenas um empenho maior
> da nossa pseudo comunidade em concretizar essa id�ia!
> Sempre houve espa�o para todo mundo, e n�o sei porque deixaria de haver caso
> a padroniza��o se concretize!
Depende do que se padroniza. Algumas padroniza��es s�o in�teis. Outras,
apenas f�teis. Mas algumas, somente algumas, s�o realmente necess�rias.
Do contr�rio, n�o ter�amos a� a POSIX.
Acho que estou sendo repetitivo � exaust�o (nem eu ag�ento mais ler o
que escrevo... e olhe que sou bastante tolerante comigo mesmo!!!), mas
uma coisa � padronizar o packman (que com o apt-get e o synaptic n�o
causa NENHUM impacto ao usu�rio final). Outra � padronizar a
granularidade dos pacotes, isto sim causando um impacto *enorme* no dia
� dia tanto do usu�rio como do developer.
N�o faz absolutamente nenhuma diferen�a o packman da distro, quando
temos ferramentas automatizadoras (algumas at� mesmo conversoras, como o
GNUpdate!!!). Simplesmente n�o fede nem cheira!!!
Mas o problema da granularidade n�o � resolv�vel com a mesma facilidade.
> >Quer saber? Ambas as op��es s�o uma furada.
>
> Nah... :)
Neh !!! ;-)
> >Estou come�ando a concluir que a LSB se concretar num determinado
> >sistema de pacotes � fria. Acho que mais importante do que impor um
> >sistema de gerenciamento de pacotes (que obviamente n�o � unanimidade
> >t�cnica nem ideol�gica), a cria��o de um mecanismo de instala��o e
> >desistena��o de aplicativos � bem mais proveitosa.
>
> Ai at� que podemos concordar, n�o vejo o porque de n�o termos um tipo de
> Install Shield para Linux sinceramente!
Isto at� que est� sendo providenciado. Com aquela id�ia maluca do GAM
que eu tive, estou dando uma pesquisada por a�, e tem sim bastante
Instaladores dando sopa pela Internet.
A maioria peca por ser simplista demais ou por querer reinventar a roda.
Exerc�cio de futilidade, pura e simples.
Algumas id�ias s�o realmente boas. O GNUpdate � um projeto deveras
interessante... Mas trabalha na abstra��o do gerenciamento de pacotes,
n�o de aplica��es. Acho que ele deveria atacar o problema mais de cima.
O instalador da Loki (que tbm � usado pelo Kylix, segundo informa��es
que obtive por aqui) ataca o problema de frente, do jeito que eu queria.
Mas t� amarrada (ao menos, foi o que conclui **superficialmente**) ao
rpm e � meio "prom�scua", n�o controlando onde se instala o qu� da
maneira que um end-luser entenda o que t� acontecendo.
O grande problema de se criar um InstallShield para Linux � justamente a
falta de padroniza��o da granularidade dos pacotes. Enquanto no Windows
a granularidade n�o poderia ser mais simples (a unidade b�sica de
instala��o � o arquivo e ponto final), no Linux pacotes com finalidades
semelhantes variam de conte�do de distro para distro, ficando muito
dif�cil controlar as depend�ncias exo-distros.... O que numa distro se
resolve em UM pacote, em outra pode estar dividida em v�rios pacotes!!!
(to be continued)
--
[]s,
Pink ------------------------------------
(Lisias Toledo) | ECHELON AT MY BALLS !! |
Manaus/Amazonas/Brasil | Will My Freedom Be Forever Denied? |
--------------------------------------------------------------------
/"\ CAMPANHA DA FITA ASCII - CONTRA MAIL HTML
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X
/ \ Movimento Pr�-acentua��o:
/ \ Use "MIME, quoted-printable, ISO-8859-1" em seu e-mailer.
Assinantes em 12/12/2001: 2362
Mensagens recebidas desde 07/01/1999: 146000
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
