Introducción En linux tenemos diversas formas de instalación de software (paquetes), la más usual y preferida por los usuarios de sistemas de escritorio es mediante un gestor de paquetes, el cual es una pieza de software que se conecta a internet, a una "librería" (repositorio) de software, para bajar, instalar software junto con sus dependencias (es decir, todo aquello que un programa necesita para funcionar) y actualizar los programas e incluso el sistema. de forma automática ... básicamente al gestor de paquetes en una primera instancia se le indica en qué repositorios buscar software (usualmente solo en la instalación de la distribución) y se "actualiza", bajando ficheros con la lista de todos los programas en ese repositorio, sus autores,descripción, dependencias, etc... también podemos compilar los programas que vienen en comprimidos en caso de no estar en los repositorios, o en caso de que siquiera tengamos gestor de paquete... si bien, la mayoría de las distribuciones incluye un gestor de paquetes propio o hereda el mismo de su distribución padre, esto no significa que haya distribuciones como Slackware, que carecen de un gestor de paquetes en el sentido completo de la palabra o simplemente no tiene resolución de dependencia (es decir, no verifica e instala programas que necesitamos para poder ejecutar el que vamos a instalar, queda a nuestro cargo) En este manual vamos a ver los métodos de instalación de las distribuciones más populares al estilo "cheat sheet" ... y la forma manual de hacerlo nótese que las formas de instalación se heredan como mencioné, así que el mismo método aplica tanto en debian como en ubuntu por ejemplo además, en algunos casos, los niveles requeridos y terminología usada son distint@s (como por ejemplo, Ubuntu se mantiene lo más simple posible y en gentoo se pide un mayor piso de conocimiento) Los comandos de instalación/actualización y borrado de paquetes requieren ser ejecutados como el usuario administrador o superusuario (el usuario llamado "root) Debian/UbuntuEn el caso de debian, tenemos el gestor de paquetes propio de la distribución "Debian PacKage manaGer" y un formato de paquete propio : .deb (si descargamos software de terceros, debe ser en este formato), y tenemos diferentes utilitarios para hacer uso de el : apt-get, aptitude y dpkg también tenemos una herramienta gráfica muy intuitiva y útil llamada synaptic, pero no siempre puede estar disponible, así que también enseñaré la forma por consola 
ConsolaActualizando la lista de softwareTenemos dos formas de hacerlo, con aptitude y con apt-get, con ambas no debería haber problemas, esto es algo que debermos realizar (dependiendo que rama usemos) más o menos seguido para poder enterarnos vía esas listas de si hay actualizaciones ... Con aptitude sería : aptitude update con apt-get : Aquí disponemos de 3 formas de hacerlo, y siempre aconsejo dos : apt-get o aptitude (preferentemente este) pero, puede que quizá dicho software NO ESTÉ en los repositorios y que debamos instalarlo de un archivo externo .deb usando dpkg los mandatos básicos para instalar son aptitude install [lista de programas] apt-get install [lista de programas] dpkg -i ./ruta-al-paquete-a-instalar.deb donde en [lista de programas] podemos poner nombres de programas separados por espacios se nos presenta un accionar (si hay que instalar/desinstalar algo) y confirmamos o no Actualizando SoftwareEsto es actualmente muy sencillo, tenemos dos formas de actualizar : full-upgrade y safe-upgrade, yo personalmente aconsejo la primera salvo que sepas lo que estés haciendo ... la diferencia entre safe y full, es que safe no borra ni instala nuevos paquetes, full sí, por eso ... de tratarse de una rama inestable, *podríamos* tener paquetes quebrados si usamos full (y por eso aconsejan safe) ... aunque para mí el inconveniente con safe es no poder deshacernos de paquetes obsoletos o poder instalar nuevos paquetes.. tú eliges ;) ¿No querés más un programa ? no hay problema, tenés dos formas de borrarlo : remove y purge remove simplemente borra el programa y purge incluye además los ficheros de configuración ... el uso es idéntico que con install : aptitude remove [lista de programas] apt-get remove [lista de programas] aptitude purge [lista de programas] apt-get remove --purge [lista de programas] Fedora/OpenSuseEn el caso de Fedora (y también OpenSuse al usar el mismo gestor de paquetes) el gestor es RPM/Yum (Yum = Yellow Dog Updater, Modified) y el formato es RPM (Es un acrónimo recursivo : RPM Package Manager .. aunque antes significaba Red hat Package Manager), las herramientas para usarlos son : yum y rpm (normalmente usaremos el primero, ya que la segunda es de más bajo nivel) Actualizando la lista de SoftwareEn el caso que querramos actualizar la lista de software para disponer de nuevo software y actualizaciones, simplemente tipeamos: Si nos interesa buscar algún software en particular buscando por nombre/descripción/sumario (ideal si no conocés el nombre del paquete, pero sabés alguna palabra relacionada con el), simplemente tipeás : yum search [expresión] Si nos interesa buscar en paquetes instalados, también podemos usar yum search, o sino, más específicamente rpm : rpm -qa con esto estaríamos generando la lista de todo el software instalado, podemos acotarla a lo que nos interesa usando grep, por ejemplo : rpm -qa | grep -i chrome Instalando SofwareYumPara instalar software, simplemente tipeamos yum install [expresión] RPMPara instalar un archivo rpm, disponés del comando "rpm" pasándole el parámetro -i (install/instalar), algo así : rpm -ivh /home/vertex/algunPaquete.rpm en mi caso agregué el "vh" (verbose y hash mark) para mostrar algo más de información mientras se instala el paquete ... Actualizando softwareEn caso que quieras actualizar tu software tenés dos opciones, la más común es usando yum, pero si tenés necesidades algo más avanzadas disponés de rpm YumEn el caso de yum es bastante sencillo, simplemente tipeamos yum update y se presentará la lista de paquetes lista para actualizar (antes actualizar la lista de paquetes/software) RPMEn este caso el procedimiento es casi igual que cuando instalamos software, con la salvedad de que cambiamos "i" por "U" (y que las versiones más viejas del paquete se borran y se instala la nueva) rpm -U /home/vertex/NuevaVersionDelPaquete.rpm Borrando SoftwareEn caso que no deseemos más un software, podemos hacerlo con rpm o yum ... YumTratándose de Yum, solo basta tipear : yum update y el paquete junto con paquetes que dependan en el se eliminarán ... RPMEn el caso de RPM, el comando es así: rpm -ev nombrePaquete nuevamente agregamos "v" para ver más detalles, pero en este caso sobre el borrado del paquete... SlackwareEn el caso de Slackware, no hay un gestor de paquetes real, sí tenemos facilidades a las que se llaman paquetes ... que básicamente son archivos .tgz o .tgx (a partir de versión 13.0) que se descomprimen en /, ejecutan un script post-instalación y se añade el paquete a la lista de paquetes en /var/log/packages un detalle a mencionar es que no hay resolución de dependencia, la cual podemos obtener mediante soluciones de terceros como swaret y slapt-get. y en este caso, como es de esperarse de la simpleza de Slackware, tenemos el método por consola ... Usando herramientas oficialesEn este caso vamos a cubrir el uso de herramientas oficiales de forma básica, herramientas como installpkg/removepkg/upgradepkg para instalar/actualizar paquetes bajados y borrar instalados ... para más información Instalando softwareEl método es bastante sencillo, teniendo el .tgz o .tgx : installpkg ./paqueteAInstalar.tgx o incluso alguna expresión con comodines, por ejemplo, instalemos todos los paquetes del directorio actual : installpkg ./*.tgx Actualizando softwareEn este caso, el viejo paquete se borra y se instala el nuevo, veamos upgradepkg ./package.tgx también podemos usar expresiones : upgradepkg ./*.tgx y un detalle, caso que un paquete se renombre, podemos ejecutar el comando de esta forma : upgradepkg viejopaquete%nuevopaquete Borrando SoftwareEn este caso, especificamos el nombre del paquete ... removepkg nano también podemos remover paquetes usando expresiones con comodines sobre /var/log/packages, pero con SUMO CUIDADO de lo que se hace removepkg /var/log/packages/kde* GentooEn el caso de Gentoo tenemos Portage como gestor de paquetes, está implementado en Python y Bash, y está inspirado en el sistema de ports de BSD, aunque tiene características avanzadas que el sistema de ports no tiene, como por ejemplo resolución de dependencias, selección de características a gusto del administrador (cosa que dispara o no dependencias), instalaciones falsas, paquetes virtuales (es decir, determinados paquetes dependen de funcionalidades que no están pegadas a un paquete en especial, sino a un paquete virtual, una funcionalidad que puede otorgar uno o más paquete, ejemplo : syslog) y slots ("ranuras", sirve para usar diferentes ramas de un paquete) Los paquetes se llaman ebuilds y a diferencia de otras distros estos no son binarios, son la descripción de cómo se compila e instala un programa o librería. lo que nos da la versatilidad de optimizar el paquete para nuestra arquitectura y compilarle/cambiarles o no determinadas carcterísticas... si bien, esta sección es prácticamente irrelevantes para los que ya instalaron el sistema (por que ya habrás usado todo lo que menciono acá y posiblemente más), sí es útil para el que quiera conocer de cómo se manejan los paquetes en gentoo .... Actualizando lista de softwareya teniendo seleccionado un mirror, procedemos a actualizar la lista con emerge --sync en caso que no quieras tanta información o que quieras ahorrar ancho de banda si estás manejando una computadora que corre gento vía ssh, podés agregar --quiet esto lo tenemos que hacer con suma responsabilidad, ya que a los que hagan sync *muy* seguido, se los banea por un tiempo ... Buscando SoftwareBuscando un Programa ? sencillo, tenemos dos formas : search y searchdesc ambas soportan expresiones regulares, veamos la primera : emerge --search gcc con esto buscaríamos en el nombre del paquete, vale destacar que --search puede cambiarse por la forma corta que es -s emerge --searchdesc gcc con esta orden buscamos todos los paquetes que incluyan gcc en el nombre o descripción, --searchdesc puede ser reemplazado por -S Esto es bastante simple y a la vez complejo, vamos por partes, para simplemente instalar un paquete esto es lo que hay que hacer : Vamos a lo un poco más complejo y a "lo que corresponde" para empezar, deberíamos partir desde /etc/make.conf así que, vamos a ello, este es el mío al día de la fecha: # Please consult /usr/share/portage/config/make.conf.example for a more # detailed example. CFLAGS="-march=native -O2 -pipe" CXXFLAGS="${CFLAGS}" MAKEOPTS="-j5" # WARNING: Changing your CHOST is not something that should be done lightly. # Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing. CHOST="x86_64-pc-linux-gnu" # These are the USE flags that were used in addition to what is provided by the # profile used for building. #agregar unicode USE="mmx sse sse2 nvidia gphoto2 vdpau xvmc multilib hald bus acpi cdr dvd usb shared_mem sockets ipv6 threads unicode posix cxx pch syslog zeroconf lm_sensors alsa ncurses session cdda cddb openal zlib gzip ogg flac faac faad vorbis speex theora mp3 mp4 mpeg lame xvid win32codecs x264 ffmpeg bluetooth crypt ssl xml libwww curl rss msn cdb mtp sqlite3 innodb truetype fontconfig raw svg svga png exif jpeg jpeg2k gif gd imagemagick openexr qt3 qt4 joystick scanner xcomposite xine xv X opengl sdl libnotify kde plasma semantic-desktop mono gimp -abiword -cups -cups-nepomuk -gcj -gnome" # Additionals : VIDEO_CARDS="nvidia" CAMERAS="canon" LINGUAS="es" ACCEPT_LICENSE="PUEL" # Mirrors GENTOO_MIRRORS="ftp://mirrors.localhost.net.ar/pub/mirrors/gentoo " SYNC="rsync://rsync.gentoo.org/gentoo-portage" para empezar, vamos por partes ... CFLAGS serían los flags de compilación de software en C, CXXFLAGS los de C++ (estamos usando los mismos que los de C) y en mi caso, el MAKEOPTS es las opciones que se pasan cuando se hace el make, en mi caso puse una construcción o build paralelo, teniendo hasta 5 trabajos (hay que aprovechar la cpu, no ? ;D ) CHOST ... básicamente se define el hardware de destino en esta variable, y se pasa a la etapa de configuración del software a compilar (./configure --host=$CHOST), no se debe tocar salvo casos específicos, es decir, como dice el texto, no es algo que pueda tomarse a la ligera, y como dice el archivo, antes de tocarlo, ver la documentación sobre el cambio de chost ahora, también tenemos USE, que es de lo que vine hablando, aquí básicamente tenemos la lista de cosas que queremos, y las que no (las que tienen un - como prefijo) esto sirve como extensión de USE que provee el perfil que usamos, a su vez, lo que tenemos en /etc/portage/package.use sirve como extensión de esto, y finalmente la variable de entorno USE que seteemos sirve como extensión (y tiene mas prioridad) que lo anterior este use en make.conf es uno general, y hay que tomar con pinzas lo que hagamos acá, ya que podemos disparar dependencias circulares (cuando dos paquetes dependen de si mismos) en mi caso hay mucha redundancia, ya que no me fijé lo que ofrece el perfil que uso (ni me importó, ya que si migro de perfil y cambia el USE, quiero conservar lo mismo) ... cada paquete que se compile, va a tener ese use, y si algo por ejemplo, tiene soporte para X (como ffmpeg), se le compila, si tiene un wrapper para mono, se le compila, si usa vorbis o zlib, se le indica que lo compile el soporte .... y así ... el resto está bien cubierto por el handbook de gentoo (mirrors, licencias, cámaras, lenguajes y tarjetas de videos ... eso y más!) también podemos setear un USE por paquete que se complementa con lo del perfil y make.conf como mencioné ... esto lo hacemos en /etc/portage/package.use y tenemos que escribir el nombre completo del paquete (categoría y nombre) veamos un ejemplo rápido : ffmpeg en la práctica ... cuando instalamos con emerge podemos simular, pretender con el flag --pretend (o simplemente -p), también pedir detalles extras de lo que se está haciendo, con --verbose (o simplemente -v, pudiendo combinarse en un -pv), es lo que se aconseja fuertemente : que revisemos si tenemos soporte de lo que queremos , las dependencias, paquetes bloqueados y demás ... veamos el caso de ffmpeg : lo que tiene como prefijo el "-" (y está en azul), es lo que no se compila, el resto sí, disparando las debidas dependencias (lo que está en rojo)... otra forma es usando gentoolkit (emerge gentoolkit) para poder ver con más detalle que es cada elemento en USE :  en mi caso, voy a agregarle soporte de documentación y dirac, agregando el nombre completo del paquete (media-video/ffmpeg) a /etc/portage/package.use, seguido de lo que quiero (aparte de lo ya soportado) : media-video/ffmpeg cpudetection network opencore-amr doc dirac y listo, ahora, para instalar sería simplemente "emerge ffmpeg" (se aconseja hacer el -pv antes para corroborar ...) y listo ... en mi caso, como ya instalé ffmpeg, le aplico el nuevo USE, reinstalando ... sería : "emerge --newuse ffmpeg" (o -N, esta acción implica update, actualizar) ahora emerge procede a bajar los paquetes con el código, configurarlos y compilarlos con lo que le instruímos ... todo solito .... compilar puede tomar más o menos tiempo, dependiendo de la cpu, pero optimizado y con soporte de sólo lo que necesitamos, teniendo un sistema más liviano ... Paquetes EnmascaradosComo veremos, no todos los paquetes están en la rama estable, aquellos paquetes que están enmascarados por ~arch (en arch va la arquitectura), son los paquetes inestables ... como bien conté, pueden haber varias ramas de un mismo paquete, como por ejemplo, en este momento kde-meta tiene la 4.3.5 y 4.4 ... o simmplemente no están lo suficientemente testeados ... para poder habilitar estos paquetes, tenemos dos formas, la general (la que aplica a los instalados y por instalar) y la "por paquete", así como con USE ... la general es agregando un ACCEPT_KEYWORDS="~amd64" (en mi caso uso esa arquitectura, cambiar con la apropiada) al make.conf, marcando que queremos TODOS los paquetes de la rama inestable (y en el próximo update, se van para esa versión), o simplemente por paquete en /etc/portage/package.keyword por ejemplo, para habilitar el chromium : www-client/chromium ~amd64 también está el hard masking, que no voy a cubrir, ya que es un tema avanzado (los paquetes que están con hard mask son por motivos especiales), para ello consultar la documentación de portage ... Bloqueo de paquetesCuando un paquete dispara un bloqueo es por que tener ambos paquetes puede quebrar el sistema o superponer archivos ... usualmente es por que ambos paquetes proveen idéntica funcionalidad ... por ejemplo : ssmtp y postfix en ese caso, aparecería de esta forma : [blocks B ] mail-mta/ssmtp ("virtual/mta" is blocking mail-mta/ssmtp-2.62-r7, mail-mta/postfix-2.6.5) en este caso indicando que ssmtp impide la instalación de postfix ... acá podemos elegir o remover ssmtp y usar postfix o quedarnos con ssmpt cuando la "B" en blocks es minúscula, significa que portage puede solucionar el problema por ejemplo borrando el viejo paquete y reinstalando el nuevo : [blocks b ] dev-libs/poppler ("dev-libs/poppler" is blocking app-text/poppler-0.12.3-r3) Dependencias circularesSi dos o más paquetes que queremos instalar dependen en sí mismos, se dispara este error ... mostrándonos el árbol de dependencias .. usualmente esto es producto de un mal uso de la variable USE en el make.conf ... (por eso hay que preferir /etc/portage/package.use ) así como un bug en portage, que se soluciona actualizando la lista de software ... en el peor de los casos, un bug que debe ser reportado en el bugzilla de gentoo : http://bugs.gentoo.org/ Borrando softwarenecesitás borrar algo ? esto es tan sencillo como emerge --unmerge nombrepaquete Nota : las dependencias pedidas por este software no se van a borrar, para eso se aconseja hacer la secuencia del update/depclean/revdep-rebuild que vemos en la sección de actualización Actualizando SoftwareDespués de tener una lista de software actualizada, podemos proceder actualizando diferentes paquetes ya sea por nueva versión o por nuevo USE ... la secuencia que suelo correr siempre es emerge --update --deep --newuse --verbose --pretend world en este caso lo nuevo es el deep para el update, deep es para escanear profundamente dependencias en búsqueda de si necesitan ser actualizadas o no (si no lo usás, probablemente quede mucho sin actualizar) , el resto es familiar o se infiere del mismo nombre ... ahora, si bien ese comando es lindo, es redundante, ya que newuse implica update, y todo se pudo usar en versiones cortas, algo así : emerge -uNDpv world siendo u --update, N --newuse, D --deep, p --pretend, y v --verbose ... hecho esto y habiendo verificado la lista, podemos sacar el pv (pretend y verbose) para proceder ... hecho esto, actualizamos paquetes, sus dependencias y recompilamos los que hayan cambiado el USE .. después de esto, podemos limpiar dependencias huérfanas, con --depclean emerge --depclean --pretend y ahí vemos si lo que se va a sacar tiene o no tiene sentido ... en caso que sí, removemos el pretend (nótese que la versión abreviada de ese comando es, naturalmente -cp ) hecho esto, tenemos que proceder a ver si hay inconsistencia en el linkeado (por ejemplo, borramos sin querer una librería) revdep-rebuild en caso que la haya, se emerge automáticamente el paquete y listo ! CompilaciónEn esta sección explico un tema que suele ser la última instancia, caso que nuestro gestor de paquete no nos provea el paquete que querramos y de la forma que querramos (versión, soporte para tal o cual cosa compilada, etc ...) GNU AutotoolsEsta es el sistema de compilación más tradicional para sistemas unix-like, aunque está empezando a ser reemplazado por otros sistemas como cmake, qmake, bjam, scons, etc ... el proceso se divide en 3 etapas : configuración, compilación e instalación ... este proceso suele ser más complicado, ya que no es automático y en caso de problemas necesitamos saber qué hacer ... en primera instancia, los paquetes pueden traer un archivo de script llamado configure o bootstrap, en caso de estar, es lo que debemos ejecutar primero ... luego opcionalmente se nos presentará una lista de características que se le compilarán al paquete (y las que no, siendo agregables instalando las dependencias necesarias, es decir, los paquetes de desarrollo que se indican) y en caso de faltar algo necesario, en esta etapa lo veremos ... hecho esto, se genera un archivo "Makefile", con instrucciones de compilación, que el comando "make" interpreta para hacer diferentes cosas con el paquete (entre esas compilar e instalar) ahora para compilar... simplemente ejecutamos make en caso que querramos indicarle a make que trate de hacer más tareas en paralelo, podemos sugerirselo mediante el flag -j make -j3 para hacer uso de 3 tareas en paralelo una vez finalizado, procedemos a convertirnos en root mediante el comando "su" y hacemos un make install make install y después de esto, opcionalmente para limpiar el espacio podemos hacer un make clean (que va a borrar los archivos objetos que hayan quedado en el directorio con el código, dejando solo el Makefile, que más tarde podemos usar para desinstalar el software con un "make uninstall") CMakeCMake (que significa "Cross platform MAKE") a diferencia de otros sistemas, es básicamente un generador de un sistema de build .. es decir, a diferencia de otros sistemas genera desde Makefiles de Unix a .sln de Visual Studio desde un conjunto de reglas escritas en CMakeLists.txt (que a diferencia de Make contiene aquí -o en módulos- la configuración y instrucciones de compilación e instalación del software) básicamente estando en el directorio con el CMakeLists.txt, creamos un directorio donde terminarán los binarios, yo usualmente lo llamo build ... mkdir build cd build y ahora tenemos tres formas de generar el sistema de build con CMake ... vamos por orden de dificultad... (más fácil a díficil) la más simple es usando la interface gráfica basada en Qt, indicando que build es donde compilar y que donde está CMakeLists.txt es donde está el source ... dando a configure, elegimos el sistema de build (usualmente Unix Makefiles) y en caso de que todo marche bien y no querramos cambiar nada, damos a configure de nuevo y después a generate ... la otra es usanco ccmake que es el comando cmake, pero con interface basada en curses ... acá es simple, estando en build, le pasamos como parámetro el donde se encuentra CMakeLists.txt (en ".." básicamente) presionamos c, esperamos a que configure, vemos los valores y en caso que no haya nada que tocar, c de nuevo y para generar "g" .... después tenemos cmake, que lo ejecutamos como ccmake la primera vez para hacer el configure, y en caso de necesitar modificar algo, lo ejecutamos pasándole "-D VARIABLE:TIPODEDATOS=VALOR" o sino, ejecutando cmake en modo interactivo (indicando -i antes del directorio) hecho esto, podemos proceder como con Autotools, haciendo el make y el make install .. (y el opcional make clean) Referencias
|
Sistemas Operativos > GNU/Linux >
