Continua��o...
> Cristiano Sina wrote:
> Uma coisa que andei pensando desde quando surgiu este assunto na lista, o
> que impede de, por exemplo em um software ser colocado "dentro" de uns
> "Install Shield" e, ao mesmo tempo em que se resolvem muitos problemas para
> os "usu�rios empurradores de mouse", os autores dos pr�prios softwares n�o
> poderiam incluir as libs e outras "cositas m�s" que se fazem necess�rias
> para o correto funcionamento do software "empacotados" junto deste sistema
> de instala��o?
� este o grande pepino que tenho que resolver, se n�o quiser pagar um
king-kong com o GAM. A partir do momento que eu enfio libs de sistema no
pacote, eu acabo amarrando ele � uma determinada distro, independente do
packman usado.
Mesmo que meu aplicativo n�o ligue para que vers�o da glibc2 (pra usar
um exemplo bem besta) estou usando, alguns pacotes nativos da distro
ligam! Eu acabo tendo que enfiar ent�o uma vers�o de cada lib do planeta
no diabo do pacota�o... Se eu tiver ent�o que montar um pacot�o
InstallShield para cada distro do planeta, que impacto me causa o
gerenciador de pacotes?
De repente, meu aplicativo precisa da �ltima vers�o do Mesa3D, mas a
distro que meu usu�rio usa ainda usa a anterior... Da� eu enfio a �ltima
vers�o de qualquer jeito, e alguns pacotes nativos chiam...
Ainda pior, a distro do usu�rio faz um update 2 meses depois neste
pacote, eu n�o fico sabendo, e meu aplicativo quebra, porque na distro
que EU USO, a granularidade do Mesa3D � maior e dando um update nela, eu
dou update automaticamente em outra biblioteca que na distro do usu�rio
fica em outro pacote, da� meu aplicativo no micro do cara usa um Mesa3D
atual, mas outra lib qualquer ainda velha, e fica mais doido que Maluco
Beleza na Rockonha...
> Pergunto eu, isto n�o poderia ser uma "sa�da" para a t�o problem�tica
> "crise" de depend�ncias????
> Se eu estiver errado, �por favor me corrijam, mas quero base t�cnicas
> inclusas nos "porques" da n�o poss�bilidade!
Cara, o problema � que voc� est� **CERT�SSIMO**. O que n�o est� pegando
muito legal � o tempero que vc quer por no assado. Em mi�dos, vc
acredita que a mera padroniza��o do packman de uma distro � suficiente
para viabilizar isto, enquanto eu acredito que o packman simplesmente
n�o faz diferen�a com as ferramentas que est�o saindo hoje!
> :)
%-P
> >Com ferramentas autom�ticas de gerenciamento de pacotes (como o apt-get
> >e Synaptic), padroniza��es nesta camada de abstra��o s�o exerc�cio de
> >futilidade.
>
> Hmmm creio que n�o, tudo � uma quest�o de bom senso!
> N�o acho que se tornaria f�til n�o, o windows recentemente vem de f�brica
> com uma "ferramenta" de atualiza��o do sistema e continua tendo seus simples
> .exe's
A simplicidade da ferramenta � desej�vel. Mas o total descontrole dos
arquivos exigido para esta abordagem n�o.
� muito mais f�cil gerenciar vers�o de 743 pacotes (exatamente o n�mero
de pacotes que acabo de instalar no meu servidorzinho que acaba de ser
recauchutado pela en�sima vez) do que 65.000 arquivos (mais ou menos o
n�mero de arquivos no meu servidor agora, tirando o /etc, /proc, /dev,
/var e o /home).
> Que de novo volto a tocar no assunto, extrai as .dlls .ocxs e outros
> arquivos pelo sistema (t� t�...concordo, de forma desordenada, mas...de
> certa forma at� que funciona, poderia ser mais um motivo para a comunidade
> linux, provar seu valor, e fazer uma coisa descente!)
Mas para isto acontecer, tanto faz o packman. O *conte�do* dos pacotes
deve ser padronizado, ou n�o ser� poss�vel criar depend�ncias
"universais", sem as quais eu sou obrigado a criar um pacote de
aplicativo (ou um mini-InstallShield diferente) para cada distro do
planeta.
N�o � poss�vel criar, ent�o, um sistema semelhante ao InstallShield no
Linux.
Mas eu estou propondo um esquema que visa criar funcionalidade
semelhante usando outros m�todos. Nesta metodologia que quero propor
(granularidade a n�vel de Aplica��o), o packman da distro simplesmente
n�o fede nem cheira, desde que me forne�a 1/2 d�zia de servi�os b�sicos
(o que parece que o SlackPack n�o fornece, Caio!! V� isto pra mim!!!), e
eu crie um mecanismo de equival�ncia de pacotes.
> >O usu�rio final n�o se beneficia, e o mantenedor tbm n�o.
>
> N�o?????
> Ok, vamos analisar a fundo! :)
Se eu sou obrigado a criar pacotes para cada distro do planeta, e
sabendo que existem front-doors que automatizam a cria��o de pacotes,
qual o benef�cio tang�vel que a padroniza��o do packman fornece ent�o ao
usu�rio e ao developer?
O usu�rio, hoje, simplesmente n�o tem contato direto com o packman. Ele
usa front-doors e bots que fazem o servi�o sujo para ele.
O developer continuaria tendo que criar pacotes para cada distro em que
ele deseja atuar. A �nica diferen�a � que o makefile dele t� 3 linhas
menor, j� que ele s� precisa gerar um tipo de pacote (rpm).
> Seria mais trabalhoso pra um mantenedor, concordo mas pense no futuro....
> O usu�rios, vendo a "facilidade" viram em maior n�mero para o sistema, mais
> pessoas se sentiram mais a vontade, sem medos....
Mas este futuro que vc vislumbra n�o passa pela padroniza��o dos
packman, mas sim pela padroniza��o da granularidade dos pacotes.
> Creio que ficaria bom para ambos os lados, a facilidade para o usu�rio e a
> $$$$$ para as distros devido a alta ades�o de novos usu�rios!
O que eu acho que favorece ambos os lados � um mecanismo facilitado que
permita ao usu�rio instalar seus aplicativos alien�genas de forma
simplificada, e depois capar eles fora de forma segura.
Os pacotes dos aplicativos nativos da distro devem ficar ao encargo da
mantenedora da distro. Cada distro que fa�a o que achar melhor. As que
estiverem certas sobreviver�o e pronto.
As aplica��es que as distros mant�m oficialmente devem ficar � seu
encargo tbm. Se elas v�o usar a interface facilitada que proponho ou uma
pr�pria, esculpida sob medida para suas necessidades, simplesmente n�o
faz diferen�a, contanto que o usu�rio possa instalar e desinstalar com
seguran�a. Assim, cada distro tem a sua "cara", e ataca o nicho de
mercado que acha que vale a pena.
> >Hummm... Chegamos � uma unanimidade!!!! 8-)
>
> N�o creio... :)
> Aposto que muitos pensam como eu, alias... n�o vejo o porque do n�o!
> O sistema cresceria MUITO se est� padroniza��o se concretiza-se, seria um
> ENORME SALTO para o sistema!
Eu n�o consigo enxergar no qu� a padroniza��o do packman tanto facilita
a vida das pessoas.
Por outro lado, a padroniza��o da granularidade da distro realmente
facilitara muito a vida de todo mundo... Mas isto tem um custo.
Se a granularidade dos pacotes for padronizada, por infer�ncia concluo
que tbm as funcionalidades o ser�o. As distros, ent�o, acabariam todas
iguais e perder�amos nosso maior trunfo, a pluralidade de distribui��es
Linux!!!
As pessoas n�o concordam nem com o packman que querem usar. Em apenas 2
horas de pesquisa, encontrei 6 tipos diferentes de packman por a�... E
nem tava procurando por eles...
Vc deve concordar comigo que a comunidade � tudo, menos uniforme. A
pluraridade de id�ias e egos � tal que a coisa beira o caos
incontorn�vel. No entanto, � deste caos que se tira a seguran�a da
subsist�ncia!
Isto implica que, n�o importa o que aconte�a no futuro (exceto um
meteoro caindo na nossa cuca ou uma bomba at�mica torrando o planeta), o
Linux ter� um sistema de pacotes adequado.
--
[]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: 146001
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
