Re: .deb vs rpms
Kov, se você conseguiu instalar os debs do Helix Code em unstable sem dar conflito de pacotes, putz, conta essa pra comunidade Debian mundial, porque todo mundo quer saber :) Eu instalei num stable e funcionou perfeitamente. Acho que só gmc que não instalou por problema de conflito. []'s Hélio Alexandre Lopes Loureiro http://helio.loureiro.eng.br [EMAIL PROTECTED] Floripa - SC - Brazil
Re: .deb vs rpms
On qua, 03 jan 2001 02:20:43 Frederico S. Muñoz wrote: On Tue, Jan 02, 2001 at 11:17:25AM -0200, Cesar Cardoso wrote: On sex, 29 dez 2000 22:04:22 Frederico S. Muñoz wrote: Até agora para provar a superioridade dos deb bastava referir o apt-get install Para que isso acontecesse, um erro básico foi cometido: acreditar que o apt fazia parte do sistema dpkg. Se o apt foi planejado desde o início para ser o mais independente possível do sistema de packaging usado, usar o apt como vantagem da Debian era algo que não fazia sentido a longo prazo. Fazia - e faz - sentido porque o apt foi desenvolvido pela Debian de forma a melhorar o sistema de instalação; o facto de ter sido adicionado suporte para RPM não invalida este ponto, porque durante algum tempo nenhuma outra distribuição o utilizou. Continuo discordando frontalmente. Se o dpkg fosse ruim, mesmo com o apt sendo o que é o sistema não conseguiria esconder a ruindade do dpkg. As vantagens do dpkg são do dpkg, e não do apt. Confundir dpkg e apt é um erro básico que as pessoas cometem. Estão fazendo um carnaval em cima de um não-problema. A utilização do subset do RPM como padrão binário não vai mudar coisa alguma nas distros GNU/Linux. Até porque a única que talvez tivesse que se adaptar (Slackware) não pertence ao grupo, e certamente o Patrick deve estar achando que essa história toda é baboseira, e vai mandar a padronização tomar vocês-sabem-bem-onde. De facto... o Slackware é distribuido agora pela BSDi e tem duas versões: stable e current; seja o que for que se passe no GNU/Linux o Slackware nem ai dar por isso, e o mais provavel é adoptar o sistema de ports ;) Só uma observação: o Slackware é distribuído pela BSDi porque o Patrick ainda não é super-homem para ele mesmo distribuir... =) Bem, o Slackware sempre foi meio BSD Linux ;) Quanto ao não-problema: cada vez que se fala em standadrd e padronização é normal que as pessoas fiquem inquitos, não porque seja algo inerentemente mau mas porque a quantidade de informação sobre o assunto é contraditória e vaga, não se sabendo exactamente quais os planos em concreto, directivas a médio prazo, etc. Tem um monte de gente falando um monte de abobrinhas. Seja como fôr, subset ou não, a nível de utilização permanece que os RPM de diferentes distribuições são incompativeis (o mesmo pode vei a acontecer com debs da Strom e Progeny). E tambem que um RPM contem uma quantidade de regras e informação bastante menor que um deb. Faltou os debs da Helix Code, que vivem num mundo à parte - e dane-se quem tem Debian. Aliás, os debs, os RPMs e tudo o mais. Será que o Miguel de Icaza se acha tão superior às distros? -- - Cesar Suporte, Linux Solutions S/C Debian GNU/Linux 2.2 possui uma instalação mais aerodinâmica e mais polida (...) (Lido no site www.linuxstore.com.br)
Re: .deb vs rpms
On qua, 03 jan 2001 16:09:04 Gustavo Noronha Silva (KoV) wrote: Faltou os debs da Helix Code, que vivem num mundo à parte - e dane-se quem tem Debian. Aliás, os debs, os RPMs e tudo o mais. Será que o Miguel de Icaza se acha tão superior às distros? eu naum peguei os sources dos debs da Helix, mas naum achei nada de errado neles... eles se instalaram perfeitamente tanto no meu potato quanto no meu woody e agora no meu sid... Kov, se você conseguiu instalar os debs do Helix Code em unstable sem dar conflito de pacotes, putz, conta essa pra comunidade Debian mundial, porque todo mundo quer saber :) -- - Cesar Suporte, Linux Solutions S/C Debian GNU/Linux 2.2 possui uma instalação mais aerodinâmica e mais polida (...) (Lido no site www.linuxstore.com.br)
Re: .deb vs rpms
On Wed, Jan 03, 2001 at 04:54:43PM -0200, Cesar Cardoso wrote: Kov, se você conseguiu instalar os debs do Helix Code em unstable sem dar conflito de pacotes, putz, conta essa pra comunidade Debian mundial, porque todo mundo quer saber :) bem... hehehe acompanhe as informacoes: um `dpkg -l | grep helix` produz: ii abiword0.7.11-helix2 WYSIWYG word processor based on GTK. rc dia0.86-helix1Diagram editor rc gaim 0.10.3-helix1 GTK clone of AOL Instant Messenger ii gcd2.95-helix1a GTK-based CD player. ii gdk-imlib-dev 1.9.8.1-helix6 Header files needed for Gdk-Imlib developmen ii gdk-imlib1 1.9.8.1-helix6 Gdk-Imlib is an imaging library for use with rc gedit 0.9.3-helix1 small, lightweight gnome-based editor for X1 ii ghex 1.1.3-helix1 a binary editor ii glade-gnome0.5.11-helix1 A Gtk+/Gnome User Interface Builder ii gmc4.5.51-helix3 Midnight Commander - A powerful file manager ii gnome-applets 1.2.4-helix1 Applets for the GNOME Panel ii gnome-bin 1.2.8-helix2 Miscellaneous binaries used by Gnome ii gnome-control- 1.2.2-helix2 The Gnome Control Center ii gnome-core 1.2.4-helix2 Common files for Gnome core apps ii gnome-gv 0.95-helix3GNOME PostScript/PDF viewer rc gnome-help 1.2.4-helix1 GNOME help browser ii gnome-iconedit 1.2.0-helix1 Icon editor for the GNOME Desktop Environmen ii gnome-libs-dat 1.2.8-helix2 Data for Gnome libraries ii gnome-panel1.2.4-helix2 Launch and/or dock Gnome applications ii gnome-panel-da 1.2.4-helix2 Data files for GNOME panel ii gnome-session 1.2.4-helix2 The Gnome Session Manager ii gnome-utils1.2.1-helix3 Gnome Utilities (gtt, ghex, and more) ii grdb 0.2.4-helix1 set X resources of legacy apps based on your ii gtk-engines-pi 0.10-helix2Pixmap-based theme for GTK+ ii guile1.3 1.3.4-helix2 Scheme interpreter, and shared libraries for ii imlib-base 1.9.8.1-helix6 Common files needed by the Imlib/Gdk-Imlib p ii imlib-progs1.9.8.1-helix6 Configuration program for Imlib and GDK-Imli ii imlib1 1.9.8.1-helix6 Imlib is an imaging library for X and X11 ii libart-dev 1.2.8-helix2 The Gnome canvas widget -- development packa ii libart21.2.8-helix2 The Gnome canvas widget ii libcapplet01.2.2-helix2 Library for Gnome Control Center applets ii libgdk-pixbuf- 0.9.0-helix8 The GNOME GdkPixBuf library. ii libgdk-pixbuf2 0.9.0-helix8 The GdkPixBuf library. ii libglade-gnome 0.14-helix1Library to load .glade files at runtime (Gno ii libglade0 0.14-helix1Library to load .glade files at runtime. ii libglib1.2 1.2.8-helix1 The GLib library of C routines ii libglib1.2-dev 1.2.8-helix1 Development files for GLib library ii libgnome-dev 1.2.8-helix2 The Gnome libraries -- development package ii libgnome32 1.2.8-helix2 The Gnome libraries ii libgnomeprint- 0.25-helix1The GNOME Print architecture (binary files) ii libgnomeprint- 0.25-helix1The GNOME Print architecture (data files) ii libgnomeprint1 0.25-helix1The GNOME Print architecture ii libgnomeprint6 0.20-helix1The GNOME Print architecture ii libgnomesuppor 1.2.8-helix2 The Gnome libraries (Support libraries) ii libgnomeui32 1.2.8-helix2 The Gnome libraries (User Interface) ii libgnorba-dev 1.2.8-helix2 Gnome CORBA services -- development package ii libgnorba271.2.8-helix2 Gnome CORBA services ii libgnorbagtk0 1.2.8-helix2 Gnome CORBA services (Gtk bindings) ii libgtk1.2 1.2.8-helix2 The GIMP Toolkit set of widgets for X ii libgtk1.2-dev 1.2.8-helix2 Development files for the GIMP Toolkit ii libgtkxmhtml1 1.2.8-helix2 The Gnome gtkxmhtml (HTML) widget ii libgtop1 1.0.9-helix2 Libraries for gtop system monitoring library ii libguile6 1.3.4-helix2 `libguile.so.6' shared libraries for Guile1. ii libguile6-slib 1.3.4-helix2 SLIB support for guile1.3 and libguile6. ii libpanel-apple 1.2.4-helix2 Library for Gnome Panel applets - Developmen ii libpanel-apple 1.2.4-helix2 Library for Gnome Panel applets ii libpopt0 1.5-helix2 lib for parsing cmdline parameters ii libpspell2 0.11.0.1-helix Portable spell checker interface library ii librep90.13.3-helix1 an embeddable Emacs-Lisp-like runtime librar ii libunicode00.4.0-helix3 The GNOME Unicode library. ii libxml11.8.10-helix1 GNOME XML library ii libzvt21.2.8-helix2 The Gnome zvt (zterm) widget ii mc 4.5.51-helix3 Midnight Commander - A powerful file manager ii mc-common 4.5.51-helix3 Common files for mc and gmc ii memprof0.4.0-helix1 memory profiler and leak detector rc pan0.9.1-helix2 Pimp A** Newsreader (Uses GTK, looks like Fo ii pspell-ispell 0.10.2-helix1 ispell interface for the pspell package ii xmms 1.2.4-helix1
Re: .deb vs rpms
On Wed, 3 Jan 2001 19:24:41 -0200 Gustavo Noronha Silva (KoV) [EMAIL PROTECTED] wrote: On Wed, Jan 03, 2001 at 04:54:43PM -0200, Cesar Cardoso wrote: Kov, se voc_ conseguiu instalar os debs do Helix Code em unstable sem dar conflito de pacotes, putz, conta essa pra comunidade Debian mundial, porque todo mundo quer saber :) bem... hehehe acompanhe as informacoes: Eu também tenho muito helix instalado e sem conflito. O que pode ser a diferência, é que estou com unstable desde faz muito tempo (antes woody) y só teve que reajustar algumas coisas manualmente em momentos isolados. Instalando isto desde zero pode ser bem diferente. Como é _unstable_ o conselho será fazer manualmente até resolver todos os conflitos, pacote a pacote. -- Christoph Simon [EMAIL PROTECTED] --- ^X^C q quit :q ^C end x exit ZZ ^D ? help shit .
Re: .deb vs rpms
On sex, 29 dez 2000 22:04:22 Frederico S. Muñoz wrote: Até agora para provar a superioridade dos deb bastava referir o apt-get install Para que isso acontecesse, um erro básico foi cometido: acreditar que o apt fazia parte do sistema dpkg. Se o apt foi planejado desde o início para ser o mais independente possível do sistema de packaging usado, usar o apt como vantagem da Debian era algo que não fazia sentido a longo prazo. Por isso e que sou terminantemente contra qualquer tentativa de uniformização de 'formato binário' para GNU/Linux por via de RPM. O que vai ser utilizado é um *subset* do RPM. Subsets não significam coisa alguma além de serem subsets; todos os RPM incompatíveis usam o mesmo subset RPM básico :) Estão fazendo um carnaval em cima de um não-problema. A utilização do subset do RPM como padrão binário não vai mudar coisa alguma nas distros GNU/Linux. Até porque a única que talvez tivesse que se adaptar (Slackware) não pertence ao grupo, e certamente o Patrick deve estar achando que essa história toda é baboseira, e vai mandar a padronização tomar vocês-sabem-bem-onde. -- - Cesar Suporte, Linux Solutions S/C Debian GNU/Linux 2.2 possui uma instalação mais aerodinâmica e mais polida (...) (Lido no site www.linuxstore.com.br)
Re: .deb vs rpms
On Tue, Jan 02, 2001 at 11:17:25AM -0200, Cesar Cardoso wrote: On sex, 29 dez 2000 22:04:22 Frederico S. Muñoz wrote: Até agora para provar a superioridade dos deb bastava referir o apt-get install Para que isso acontecesse, um erro básico foi cometido: acreditar que o apt fazia parte do sistema dpkg. Se o apt foi planejado desde o início para ser o mais independente possível do sistema de packaging usado, usar o apt como vantagem da Debian era algo que não fazia sentido a longo prazo. Fazia - e faz - sentido porque o apt foi desenvolvido pela Debian de forma a melhorar o sistema de instalação; o facto de ter sido adicionado suporte para RPM não invalida este ponto, porque durante algum tempo nenhuma outra distribuição o utilizou. Agora, o software livre é livre por isso mesmo, é para ser aproveitado, modificado, etc, e ainda bem que assim é. Por isso e que sou terminantemente contra qualquer tentativa de uniformização de 'formato binário' para GNU/Linux por via de RPM. O que vai ser utilizado é um *subset* do RPM. Subsets não significam coisa alguma além de serem subsets; todos os RPM incompatíveis usam o mesmo subset RPM básico :) A verdade é que já li tanta informação contraditória sobre isto tudo que já não sei o que hei-de pensar. Honestamente parece-me que não vai acrescentar nada em termos de facilidade e compatibilidade, mas o tempo o dirá, não sei que projesctos estão pensados. Estão fazendo um carnaval em cima de um não-problema. A utilização do subset do RPM como padrão binário não vai mudar coisa alguma nas distros GNU/Linux. Até porque a única que talvez tivesse que se adaptar (Slackware) não pertence ao grupo, e certamente o Patrick deve estar achando que essa história toda é baboseira, e vai mandar a padronização tomar vocês-sabem-bem-onde. De facto... o Slackware é distribuido agora pela BSDi e tem duas versões: stable e current; seja o que for que se passe no GNU/Linux o Slackware nem ai dar por isso, e o mais provavel é adoptar o sistema de ports ;) Quanto ao não-problema: cada vez que se fala em standadrd e padronização é normal que as pessoas fiquem inquitos, não porque seja algo inerentemente mau mas porque a quantidade de informação sobre o assunto é contraditória e vaga, não se sabendo exactamente quais os planos em concreto, directivas a médio prazo, etc. Seja como fôr, subset ou não, a nível de utilização permanece que os RPM de diferentes distribuições são incompativeis (o mesmo pode vei a acontecer com debs da Strom e Progeny). E tambem que um RPM contem uma quantidade de regras e informação bastante menor que um deb. um abraço, fsm -- Frederico S. Muñoz GNU http://www.gnu.org [EMAIL PROTECTED] Debian http://www.debian.org http://sdf.lonestar.org - SDF Public Access Unix Systems
