Imprescindible documento de Paulet de FentLinux en el que ya en el 2004 se analizaban todos los secretos de la herramienta más potente de Debian -y por extensión de los sistemas derivados: el APT. Ahora actualizado. Como digo, imprescindible.
#4:
#3 Al hilo de lo que dices, imagina por un momento estandarizar todo el software existente en Linux en paquetes *.deb y la instalación mediante gdebi, apt o synaptic. Aunque manteniendo cada distro su propia filosofía y esencia, el avance sería sencillamente espectacular.
#9:
#8 aptitude se puede utilizar como apt-get. En lugar de poner "apt-get install pr0n" pones "aptitude install pr0n", voila.
#12:
#11 A que los micros con 8 cores sean algo habitual y así poder compilar KDE en menos de un día
#7:
¿Cómo? ¿No aparece ni mencionado el aptitude? Si hasta la propia Debian lo recomienda por encima del apt-get "a pelo" en sus guías...
#3:
No se a que cojones estan esperando las demas distribuciones para cambiar a apt.
#3 Al hilo de lo que dices, imagina por un momento estandarizar todo el software existente en Linux en paquetes *.deb y la instalación mediante gdebi, apt o synaptic. Aunque manteniendo cada distro su propia filosofía y esencia, el avance sería sencillamente espectacular.
#7 Ciertamente, Hass. Ahora bien, como dice la Wikipedia, aptitude es un frontispicio para APT: Y el artículo trata sobre APT, no sobre apt-get (no se si me explico).
ah... qué haría sin apt...
siempre que veo a alguien instalar algo (windows o no-apt/deb-linux) le largo el rollo de:
con lo fácil que es debian! apt y listo!
Apt me encanta y en su día me abrió un mundo, pero ahora personalmente prefiero smartpm, tiene muchas cosas en común con apt y permite usar más tipos de repositorios. Merece la pena probarlo.(y le da igual si es rpm o deb )
La mejora que me gustaría ver sería que se instalaran los paquetes desde binario y luego, como tarea de fondo, se descargaran las fuentes y se compilaran, para, una vez creado el nuevo paquete, instalarlo sustituyendo al antiguo.
Vale que sería más trabajo y más trasiego de datos, pero se tendría lo mejor de APT y de emerge (EMHO).
A lo mejor es porque soy un newbie, pero una de las pegas que le veo a apt es a la hora de desinstalar. Por ejemplo:
apt-get install kde
te instala el entorno kde completito, unos 600MB
apt-get remove kde
te desinstala kde, unos 40KB
Os digo, a lo mejor es porque soy un newbie y no se hacerlo (y si es algo trivial os agradecería el cable, porque ya me he RTFM varias veces) pero creo que es una de las grandes pegas de apt. ¿no?
apt, e ahi la razon por la que me quede con mi debian... aunque el pacman de archlinux no es k le tenga mucho k envidiar, a veces hecho de menos archlinux...
En fin, en la variedad esta el gusto. Larga vida a apt, debian y a GNU/Linux
#27 Con la fusión de Conectiva y Mandriva se comentó de una posible fusión entre smart y urpmi. Creo que se va a intentar la fusión de ambas tecnologías en próximas ediciones e Mandriva.
Apt sigue teniendo para muchos un "problema"... el soporte bi-arch, es decir, en sistemas compatibles con dos arquitecturas la posibilidad de usar el mismo software para esas arquitecturas sin estar con líos extraños (hacer la jaula, duplicar muchas cosas luego...).
Esto mismo yum, el gestor de RPM de muchas distros basadas en red hat, lo resuelve: en un sistema amd64, yum install firefox, me instala firefox para i386 y para x86_64 a la vez. Si quiero solo i386 hago yum install firefox.i386
Es una ventaja que tiene yum, que muchos esperamos que realicen en apt. Lo que pasa es que las distros basadas en debian quieren ser "Pure64", y la realidad... por ahora es otra.
#2 El rpm no es tan malo como le pintan. Mandriva tiene una herramienta de gestión de paquetes rpm que no tiene nada que envidiar al apt de Debian. La herramienta es urpmi (licencia GPL) y en Blogdrake puedes ver algunos artículos comparando apt y urpmi. Sencillamente apt aventaja en unos casos a urpmi y esta la aventaja en otros.
#7 que quieres que te diga, no tengo ni puta idea de utilizar aptitude, me meto dentro, quiero desinstalar una cosa y menos desinstalar hago cualquier burrada jejejeje.
#4 no ves como me gustaria eso, ya que algunos proyectos solo hay rpm's. Ahora con Ubuntu tenemos un aliado, algo bueno tendria que tener ubuntu no?
Y sin embargo la LSB establece como formato de paquete estándar el RPM. Sí, GNU/Linux tampoco está exento de influencias y politiqueos. Si Debian cumple con la LSB es por alien.
Yo lo que hecho en falta es una herramienta capaz de dar marcha atras en cualquier tipo de actualización masiva de software, y dejarlo todo como estaba. Es muy inusual, pero algunas veces se desconfigura algo importante que cuesta bastante volver a configurar, y si no conoces perfectamente lo que ha quedado mal configurado puedes tardar bastante en recuperar la normalidad.
Hass, gracias por haber dicho lo que muchos pensamos.
Si no se usa aptitude, el sistema conserva cada vez más código que nunca usará, y el autoremove de apt-get no lo soluciona del todo, eso sí, muchas veces complementa a aptitude y deborphan.
Limpiando con aptitude un Debian envejecido prematuramente por haber estado usando apt-get:
#18 pues qué quieres que te diga... hasta donde yo se apt-get o aptitude, solo son capaces de desinstalar el software que se ha instalado empleándolos a ellos mismos o dpkg, mientras que pacman es capaz de hacerlo con todo todito el software de la máquina, haya sido instalado desde pacman, AUR o mediante compilación y todo el rollo.
#34 No he intentado iniciar ningún flame, ya que he puesto que es mi opinion, pero la cpu al 100% unicamente la veras al instalar algún software nuevo, cosa que por lo menos en mi caso no hago todos los dias, y una vez instalado, la cpu al contrario, va mucho mas ligera al estar el software compilado para ese sistema concreto, pero bueno sigue siendo mi mas modesta opinion
Estos complejísimos gestores de paquetes y repositorios tan grandes que son inmantenibles son sólo un mal parche al problema que nadie quiere afrontar: la falta de estandarización que hace que Linux no sea una plataforma. La gente de autopackage lo explica mejor que yo, por si alguien quiere informarse antes de moderarme negativamente por tener otra opinión de lo que debería ser la instalación de software.
Lo que todos deseariamos es un formato de paquete estándar, ni rpm, ni deb ni emerge. Pero eso solo está en la manos de Debian, Redhat y Suse. De las demás, la mayoría caería por inercia (ubuntu, fedora, opensuse, centos, linex, knoppix, mepis...) o acabarían aceptándolo (mandriva,linspire...). Otras distros, como gentoo tienen un objetivo y unos procedimientos claramente diferentes y quizás no lo aceptarían o si.
El formato debe ser nuevo y mejor, moderno. Hay una necesidad clara de 'etiquetar los paquetes' porque la categorización ya no vale, es prehistórica. De alguna forma, totem tiene que poder preguntar por los paquetes de 'codecs' para 'gstreamer' que lean 'mp3'. Debería haber una serie de etiquetas de primer nivel: marcar las librerías, marcas programas y de que plataforma (gnome,kde,x,consola), marcar servicios, marcar librerías de desarrollo, marcar núcleos, marcar drivers...
Esto facilitaría mucho cosas como el Añadir o Quitar programas de Ubuntu y se podrían crear gestores de paquetes mucho más sencillos.
Desde luego, esto sería una cuestión a tratar a largo plazo y es muy difícil, pero ojalá.
También hay que soportar las licencias. Cuando instalo Ubuntu, da por supuesto que aceptamos las licencias como GPL, Apache, BSD u otras y en algunos paquetes se nos pregunta. Cada paquete tendría su licencia o licencias, con la posibilidad por comodidad de aceptarlas todas o las de algunos tipos por defecto, si es posible.
También debería soportarse cosas como debconf (no se si algo así existe en rpm y a que nivel, pero supongo que si) para instalaciones completamente gráficas o de texto y reconfiguraciones.
La instalación sin root, en modo usuario también debería ser contemplada, aunque desde luego sería imposible hacerlo con todos los paquetes. Podrían ir marcados de alguna forma aquellos con esa posibilidad.
La actualización incremental (solo bajar los cambios) también hay que tenerla en cuenta. Es algo complicado porque las diferencias binarias no son ni mucho menos tan eficientes como las diferencias de texto, pero con el incremento de usuarios, la necesidad es real.
El objetivo principal ha de ser obtener paquetes fuente-compatibles en contra de lo que podemos encontrar hoy, binario-compatibles. Que la mayoría de los paquetes, al menos, aquellos que no afectan directamente al sistema, aquellos que son librerías simples, aplicaciones como openoffice, mozilla, inkscape... se puedan recompilar de un sistema a otro con un comando.
Nadie espera instalar un kernel de redhat en debian, o el gnome de ubuntu en suse, pero al menos, que podamos desarrollar un reproductor de música que sea facilmente recompilable entre sistemas.
#35 Siento que hayas malentendido mi expresión, en realidad me refería a lo que yo estaba a punto de decir.
Como tú has dicho, puede resultar ventajoso cuando hay muy pocos (o directamente ninguno) cambios en las versiones de los programas, pero para los que usamos versiones de desarrollo de Debian (testing y unstable), la verdad es que podría resultar algo insostenible, desde mi punto de vista.
#25#26 Si la razón por la que es inusable, es porque no quieren darle ni un vistazo al manual, apaga y vámonos. Es cuestión de aprenderse las funciones más usadas (unas 10 a lo mucho) y listo.
Eso si, para alguien que use la rama estable puede no ser la gran cosa, pero a los que usen testing y unstable, es bastante útil.
#31 Sin ánimos de iniciar flames ridículos, creo que sólo un porcentaje pequeño de usuarios necesita y puede darse el lujo de compilar absolutamente todo. En lo personal no me atrae mucho la idea de ver mi cpu al 100% mientras trabajo, y no, nunca consideraría la opción de dejar el equipo encendido sólo para eso.
Vamos a ver, el mejor gestor de paquetes para mi gusto personal y para la gente que utiliza linux de mi alrededor es, y será (espero) emerge, eso si es una joyita, la única pega que se le puede poner, que te lo compila todo, por lo que tarda mucho, lo mejor, que te lo compila todo, y por lo tanto tienes todo tu software adaptado a tu sistema.
#8 aptitude remove programa para desinstalar manteniendo los archivos de configuración
aptitude purge programa para borrarlo todo
Una de las ventajas que tiene aptitude es que además desinstalará los paquetes que eran dependencias de este programa y que ningún otro programa está usando, cosa que apt no hace.
Comentarios
#3 Al hilo de lo que dices, imagina por un momento estandarizar todo el software existente en Linux en paquetes *.deb y la instalación mediante gdebi, apt o synaptic. Aunque manteniendo cada distro su propia filosofía y esencia, el avance sería sencillamente espectacular.
#8 aptitude se puede utilizar como apt-get. En lugar de poner "apt-get install pr0n" pones "aptitude install pr0n", voila.
#11 A que los micros con 8 cores sean algo habitual y así poder compilar KDE en menos de un día
No se a que cojones estan esperando las demas distribuciones para cambiar a apt.
¿Cómo? ¿No aparece ni mencionado el aptitude? Si hasta la propia Debian lo recomienda por encima del apt-get "a pelo" en sus guías...
Sin duda alguna, ésta ha sido durante años una de las ventajas principales de Debian frente a Red Hat, por ejemplo, y sus rpm...
#7 Ciertamente, Hass. Ahora bien, como dice la Wikipedia, aptitude es un frontispicio para APT: Y el artículo trata sobre APT, no sobre apt-get (no se si me explico).
#24 no lo digo por feo, sino por inusable...
ah... qué haría sin apt...
siempre que veo a alguien instalar algo (windows o no-apt/deb-linux) le largo el rollo de:
con lo fácil que es debian! apt y listo!
#16 Usa aptitude
Apt me encanta y en su día me abrió un mundo, pero ahora personalmente prefiero smartpm, tiene muchas cosas en común con apt y permite usar más tipos de repositorios. Merece la pena probarlo.(y le da igual si es rpm o deb )
http://labix.org/smart
Complemento a este estupendo trabajo, el recetario APT: http://www.fentlinux.com/web/?q=node/262
#16, usa apt-get autoremove , que te elimina las dependencias que fueron añadidas en la instalacion.
por cierto el apt-get que todos veneráis es una copia (mejorada) del pkg_add de FreeBSD...
La mejora que me gustaría ver sería que se instalaran los paquetes desde binario y luego, como tarea de fondo, se descargaran las fuentes y se compilaran, para, una vez creado el nuevo paquete, instalarlo sustituyendo al antiguo.
Vale que sería más trabajo y más trasiego de datos, pero se tendría lo mejor de APT y de emerge (EMHO).
A lo mejor es porque soy un newbie, pero una de las pegas que le veo a apt es a la hora de desinstalar. Por ejemplo:
apt-get install kde
te instala el entorno kde completito, unos 600MB
apt-get remove kde
te desinstala kde, unos 40KB
Os digo, a lo mejor es porque soy un newbie y no se hacerlo (y si es algo trivial os agradecería el cable, porque ya me he RTFM varias veces) pero creo que es una de las grandes pegas de apt. ¿no?
#21 Y lo mejor es que en ese menu se puede jugar al buscaminas mientras baja e instala cosas!!!11uno
#23 Es ncurses, no se puede pedir mucho La idea era reemplazar el vetusto dselect y cumple
#25 Ahí te doy la razón, no hay manera de manejarlo sin haberse leído el manual antes ( http://people.debian.org/~dburrows/aptitude-doc/en/ ), por esa razón sólo lo uso a modo de "apt-get".
Personalmente encuentro el aptitude mucho mejor. Funciona IGUAL que el apt-get. Simplemente escribid aptitude en vez de apt-get.
apt, e ahi la razon por la que me quede con mi debian... aunque el pacman de archlinux no es k le tenga mucho k envidiar, a veces hecho de menos archlinux...
En fin, en la variedad esta el gusto. Larga vida a apt, debian y a GNU/Linux
#8, no confundir con synaptic
#20 ah sí? Ni idea, lo uso igual que apt-get...
#27 Con la fusión de Conectiva y Mandriva se comentó de una posible fusión entre smart y urpmi. Creo que se va a intentar la fusión de ambas tecnologías en próximas ediciones e Mandriva.
Apt sigue teniendo para muchos un "problema"... el soporte bi-arch, es decir, en sistemas compatibles con dos arquitecturas la posibilidad de usar el mismo software para esas arquitecturas sin estar con líos extraños (hacer la jaula, duplicar muchas cosas luego...).
Esto mismo yum, el gestor de RPM de muchas distros basadas en red hat, lo resuelve: en un sistema amd64, yum install firefox, me instala firefox para i386 y para x86_64 a la vez. Si quiero solo i386 hago yum install firefox.i386
Es una ventaja que tiene yum, que muchos esperamos que realicen en apt. Lo que pasa es que las distros basadas en debian quieren ser "Pure64", y la realidad... por ahora es otra.
#3 No a se que cojones están esperando las demás distribuciones a cambiar a portage
#20 Creo que se refiere a que si ejecutas "aptitude" tal cual te presenta un menu en ncurses estilo dselect o synaptic.
#2 El rpm no es tan malo como le pintan. Mandriva tiene una herramienta de gestión de paquetes rpm que no tiene nada que envidiar al apt de Debian. La herramienta es urpmi (licencia GPL) y en Blogdrake puedes ver algunos artículos comparando apt y urpmi. Sencillamente apt aventaja en unos casos a urpmi y esta la aventaja en otros.
#7 que quieres que te diga, no tengo ni puta idea de utilizar aptitude, me meto dentro, quiero desinstalar una cosa y menos desinstalar hago cualquier burrada jejejeje.
#4 no ves como me gustaria eso, ya que algunos proyectos solo hay rpm's. Ahora con Ubuntu tenemos un aliado, algo bueno tendria que tener ubuntu no?
Y sin embargo la LSB establece como formato de paquete estándar el RPM. Sí, GNU/Linux tampoco está exento de influencias y politiqueos. Si Debian cumple con la LSB es por alien.
Yo lo que hecho en falta es una herramienta capaz de dar marcha atras en cualquier tipo de actualización masiva de software, y dejarlo todo como estaba. Es muy inusual, pero algunas veces se desconfigura algo importante que cuesta bastante volver a configurar, y si no conoces perfectamente lo que ha quedado mal configurado puedes tardar bastante en recuperar la normalidad.
Hass, gracias por haber dicho lo que muchos pensamos.
Si no se usa aptitude, el sistema conserva cada vez más código que nunca usará, y el autoremove de apt-get no lo soluciona del todo, eso sí, muchas veces complementa a aptitude y deborphan.
Limpiando con aptitude un Debian envejecido prematuramente por haber estado usando apt-get:
Limpiando un sistema GNU/Linux Debian
Limpiando un sistema GNU/Linux Debian
debian-administration.org#18 pues qué quieres que te diga... hasta donde yo se apt-get o aptitude, solo son capaces de desinstalar el software que se ha instalado empleándolos a ellos mismos o dpkg, mientras que pacman es capaz de hacerlo con todo todito el software de la máquina, haya sido instalado desde pacman, AUR o mediante compilación y todo el rollo.
#34 No he intentado iniciar ningún flame, ya que he puesto que es mi opinion, pero la cpu al 100% unicamente la veras al instalar algún software nuevo, cosa que por lo menos en mi caso no hago todos los dias, y una vez instalado, la cpu al contrario, va mucho mas ligera al estar el software compilado para ese sistema concreto, pero bueno sigue siendo mi mas modesta opinion
Estos complejísimos gestores de paquetes y repositorios tan grandes que son inmantenibles son sólo un mal parche al problema que nadie quiere afrontar: la falta de estandarización que hace que Linux no sea una plataforma. La gente de autopackage lo explica mejor que yo, por si alguien quiere informarse antes de moderarme negativamente por tener otra opinión de lo que debería ser la instalación de software.
http://autopackage.org/faq.html#5_1
Lo que todos deseariamos es un formato de paquete estándar, ni rpm, ni deb ni emerge. Pero eso solo está en la manos de Debian, Redhat y Suse. De las demás, la mayoría caería por inercia (ubuntu, fedora, opensuse, centos, linex, knoppix, mepis...) o acabarían aceptándolo (mandriva,linspire...). Otras distros, como gentoo tienen un objetivo y unos procedimientos claramente diferentes y quizás no lo aceptarían o si.
El formato debe ser nuevo y mejor, moderno. Hay una necesidad clara de 'etiquetar los paquetes' porque la categorización ya no vale, es prehistórica. De alguna forma, totem tiene que poder preguntar por los paquetes de 'codecs' para 'gstreamer' que lean 'mp3'. Debería haber una serie de etiquetas de primer nivel: marcar las librerías, marcas programas y de que plataforma (gnome,kde,x,consola), marcar servicios, marcar librerías de desarrollo, marcar núcleos, marcar drivers...
Esto facilitaría mucho cosas como el Añadir o Quitar programas de Ubuntu y se podrían crear gestores de paquetes mucho más sencillos.
Desde luego, esto sería una cuestión a tratar a largo plazo y es muy difícil, pero ojalá.
También hay que soportar las licencias. Cuando instalo Ubuntu, da por supuesto que aceptamos las licencias como GPL, Apache, BSD u otras y en algunos paquetes se nos pregunta. Cada paquete tendría su licencia o licencias, con la posibilidad por comodidad de aceptarlas todas o las de algunos tipos por defecto, si es posible.
También debería soportarse cosas como debconf (no se si algo así existe en rpm y a que nivel, pero supongo que si) para instalaciones completamente gráficas o de texto y reconfiguraciones.
La instalación sin root, en modo usuario también debería ser contemplada, aunque desde luego sería imposible hacerlo con todos los paquetes. Podrían ir marcados de alguna forma aquellos con esa posibilidad.
La actualización incremental (solo bajar los cambios) también hay que tenerla en cuenta. Es algo complicado porque las diferencias binarias no son ni mucho menos tan eficientes como las diferencias de texto, pero con el incremento de usuarios, la necesidad es real.
El objetivo principal ha de ser obtener paquetes fuente-compatibles en contra de lo que podemos encontrar hoy, binario-compatibles. Que la mayoría de los paquetes, al menos, aquellos que no afectan directamente al sistema, aquellos que son librerías simples, aplicaciones como openoffice, mozilla, inkscape... se puedan recompilar de un sistema a otro con un comando.
Nadie espera instalar un kernel de redhat en debian, o el gnome de ubuntu en suse, pero al menos, que podamos desarrollar un reproductor de música que sea facilmente recompilable entre sistemas.
#38 Para el asunto de las instalaciones mediante compilación, está checkinstall.
#42 Querrás decir las cosas que apt-get no hace
#35 Siento que hayas malentendido mi expresión, en realidad me refería a lo que yo estaba a punto de decir.
Como tú has dicho, puede resultar ventajoso cuando hay muy pocos (o directamente ninguno) cambios en las versiones de los programas, pero para los que usamos versiones de desarrollo de Debian (testing y unstable), la verdad es que podría resultar algo insostenible, desde mi punto de vista.
#25 #26 Si la razón por la que es inusable, es porque no quieren darle ni un vistazo al manual, apaga y vámonos. Es cuestión de aprenderse las funciones más usadas (unas 10 a lo mucho) y listo.
Eso si, para alguien que use la rama estable puede no ser la gran cosa, pero a los que usen testing y unstable, es bastante útil.
#31 Sin ánimos de iniciar flames ridículos, creo que sólo un porcentaje pequeño de usuarios necesita y puede darse el lujo de compilar absolutamente todo. En lo personal no me atrae mucho la idea de ver mi cpu al 100% mientras trabajo, y no, nunca consideraría la opción de dejar el equipo encendido sólo para eso.
apt es bueno pero el emerge a mi parecer es mejor (gentoo powa!)
#32 sería interesante. No recuerdo si urpmi estaba hecho en perl o en c/c++ pero smart es python así que no creo que se aburran con la posible fusión
En cualquier caso la interface de comandos de smart es más parecida a apt que a urpmi, espero que eso no lo cambien.
Vamos a ver, el mejor gestor de paquetes para mi gusto personal y para la gente que utiliza linux de mi alrededor es, y será (espero) emerge, eso si es una joyita, la única pega que se le puede poner, que te lo compila todo, por lo que tarda mucho, lo mejor, que te lo compila todo, y por lo tanto tienes todo tu software adaptado a tu sistema.
#22 pues lo estoy probando y es una mierda del tamaño de mi pueblo
#8 aptitude remove programa para desinstalar manteniendo los archivos de configuración
aptitude purge programa para borrarlo todo
Una de las ventajas que tiene aptitude es que además desinstalará los paquetes que eran dependencias de este programa y que ningún otro programa está usando, cosa que apt no hace.
#4 supongo que con esto no has intentado responeder la pregunta de #3