Era: Escritorio mas limpio
El Sat, 20 Sep 2014 05:33:01 +0200
Etemenanki <etemenanki@openmailbox.org> escribió:
> >>
> >> Si instalas algo con un interfaz y ese algo luego lo desinstalas
> >> con otro, eso otro interfaz no tiene los datos de instalación en
> >> sus registros y ahí empieza el problema de que no se desinstalen
> >> bien los paquetes.
> >>
> >> Desterrando mitos que arrastra el pobre e incomprendido Aptitude
> >> por blogs y redes sociales incoming... :-D
> >>
> >>
> >
> > No estoy de acuerdo. Suelo utilizar aptitude como norma;
> > ocasionalmente apt-get; y después de desinstalar paquetes 'para
> > pruebas', paso deborphan.
>
> Ídem en lo de aptitude. apt-get y deborphan no los suelo usar, nada
> más alguna vez por curiosidad.
>
aptitude es mi centro de paquetes, y no entiendo como es que no ha
desterrado ya a 'apt-get' (excepto usos ocasionales). La facilidad que
da para examinar paquetes y sus dependencias es tremenda. Para mantener
un entorno mínimo, es tremendamente práctica. Miras un paquete, entras
en sus dependencias, y buscas paquetes con dependencias comunes que se
adapten a las tareas que quieres.
> > apt-get y deborphan no tienen una 'base de datos' propia. Se
> > limitan a utilizar la base de datos global de dpkg, que a su vez se
> > limita a indicar los paquetes presentes en el sistema y sus
> > dependencias.
>
> deborphan ni idea por que no lo uso, apt-get no tiene una base
> propia, pero usa la de APT, que a su vez usa la de dpkg.
>
deborphan instala una utilidad llamada 'orphaner'. Se limita a buscar
paquetes que no son utilizados por ningún otro, lo que permite
desinstalarlos.
A diferencia de 'aptitude', no utiliza datos propios. 'aptitude'
recuerda los paquetes que el usuario instaló el mismo (no como
dependencias de otros), y los mantiene en el sistema. 'deborphan' no
tiene en cuenta como se instaló el paquete; si ningúno depende de él,
lo propone para desinstalar.
Por ejemplo, si instalas un paquete para alguna tarea puntual, y luego
olvidas desinstalarlo, 'deborphan' te lo muestra como paquete
susceptible de eliminar.
Otro uso: algunos paquetes dependen de una de entre varias opciones;
'phonon' (de KDE) depende de 'phonon-backend-vlc' o de
'phonon-backend-gstreamer'.
En mi caso, suelo instalar primero el backend. Si lo hago con
'aptitude' y selecciono 'phonon-backend-vlc', cuando desinstale
'phonon' me mantiene el backend, porque lo instale yo (no fue
automatico).
deborphan no tiene en cuenta eso, y siempre me propondra el backend
como paquete a eliminar.
>
> Aquí muestro algunas localizaciones para confirmarlo:
>
> aptitude
> /var/log/aptitude
> /var/lib/aptitude/pkgstates
>
> apt-get que como no tiene base propia usa la de APT
> /var/log/apt/history.log + term.log
> /var/lib/apt/...
>
> dpkg (herramienta principal también sus registros)
> /var/log/dkpg.log
> /var/lib/dpkg/...
>
> Estamos de acuerdo en que dpkg es la herramienta base (herramienta de
> bajo nivel), APT es una biblioteca considerada un frontend de dpkg
> (herramienta de alto nivel) y apt-get, aptitude, etc... son a su vez
> frontends de APT (más alto nivel aún xD).
>
> > aptitude si tiene datos propios, pero tan solo se percata de
> > paquetes ELIMINADOS; es decir, si recuerda que un paquete estaba
> > instalado y ya no lo está, propondrá su instalación. Solo propondrá
> > desinstalar un paquete, sea cual sea el método de instalación, si
> > se ha configurado para eliminar paquetes no utilizados por otros.
>
> Aptitude se percata de más cosas que solamente de los paquetes
> eliminados, mira por cada paquete los diferentes estados que hay en
> su base de datos:
>
> /var/lib/aptitude/pkgstates
>
> Package: linux-source-3.14
> Architecture: amd64
> Unseen: yes
> State: 1
> Dselect-State: 1
> Remove-Reason: 0
>
> > De cualquier forma, todos los front-ends (que eso son) terminan
> > llamando a dpkg con las opciones pertinentes; es este el que
> > realiza el verdadero trabajo.
>
La verdad es que el hecho de que 'aptitude' y 'apt-get' guarden bases
de datos separadas en una mala solución, desde el punto de vista de
mantener un sistema limpio de paquetes no usados. 'autoclean' de uno y
otro, según eso, borran paquetes distintos. OJO, que no se esto a
ciencia cierta, pero es lo que se desprende de su organización.
> Cierto, el camino completo es, frontends → APT → dpkg.
>
> > Eso implica que no quedan paquetes 'mal instalados' ni dependencias
> > incumplidas, instalemos como instalemos. dpkg se encarga de ello.
>
> Yo no he dicho que haya "problemas" al instalar, ni que queden los
> programas mal instalados, ni que queden dependencias incumplidas por
> mezclar los frontends. Lo que he dicho es que los "problemas" vienen
> al desinstalar. Que te pueden quedar resquicios por ahí, pero nada
> que un buen administrador no sepa resolver, claro está.
>
Es lo que sobrentendí referente a la frase 'y ahí empieza el problema
de que no se desinstalen bien los paquetes'.
> >
> > No confundir lo anterior con la diferencia entre 'desinstalar' y
> > 'purgar'. Lo primero deja los archivos de configuración, mientras
> > que lo segundo elimina todo.
> >
> Por supuesto, aunque espero que esa explicación no vaya
> explícitamente para mi. Creo que he demostrado sobradamente que no
> soy un novato. :-)
Era una aclaración general. El usuario que inició el hilo parece que no
se maneja muy bien con las herramientas.
>
> En un principio tuve la tentación de explicar todo esto más
> detalladamente, lo hice en plan rápido y mal, sobretodo esto último,
> pero claro, no quise hacer un post kilométrico porque no es el lugar
> adecuado y además de que el hilo va de escritorios ligeros y no de
> gestores de paquetes, espero que nadie se haya molestado. El tema es
> interesante. :-D
>
Es que por la tele estaban emitiendo 'Pequeños Gigantes' (que no me
gusta), y estaba aburrido xD. Cuestiones familiares me obligan a ver
dicho programa.
>
> Un placer comentar con gente que sabe.
>
> Saludos!
>
Solo se que no se nada, que dijo Platón ;-)
Saludos.
Reply to: