Jump to content

Como instalar programas en GNU/Linux


Mgbu
 Share

Recommended Posts

Sería útil una guía de como instalar programas en GNU/Linux para recien iniciados, porque es bastante distinto de como se maneja en Windows

Esta guia esta pensada para distribuciones (lease "tipos de Linux") basadas en Ubuntu (por lo tanto Linux Mint, Ubuntu, Xubuntu, Kubuntu, etc.). También sirve un poco para Debian.

 

Hay distintas formas de conseguir programas. Se puede usar un gestor de paquetes, instalar un paquete manualmente, copiar el ejecutable o compilarlo vos mismo

 

Con un gestor de paquetes (recomendado):

Termina siendo algo así como una tienda de aplicaciones, similar a la tienda de Android (Play Store) o la tienda de Apple (Apple Store)

Te instalan el programa, te lo agregan al menu de inicio para poder usarlo y se encargan de actualizarlo

 

Mas info:

 

 

El gestor de paquetes es un programa que consigue e instala los paquetes

Un paquete es un archivo que tiene datos o programas. Lo importante es que los programas pueden venir en paquetes

Los paquetes dependen entre ellos, por eso al instalar un paquete pueden que se descarguen varios automáticamente.

 

El gestor de paquetes descarga los paquetes (y por ende los programas) de repositorios, que son los servidores.

Uno puede elegir cuales son los repositorios que queremos usar, ver mas abajo

 

 

A fines prácticos:

Hay gestores de paquetes con interfaz gráfica y gestores que se usan desde la terminal

 

De forma grafica (mas fácil)

 

 

Hay distribuciones que están mas preparadas para usuarios principiantes (Ubuntu y Linux Mint) que tienen un gestor de paquetes muy fácil de usar.

El nombre puede variar, suele llamarse "Centro de Software".

La forma de usarlos suele variar, pero no hacen falta muchas instrucciones porque es cuestión de buscar el programa que quieras e instalar, como en las tiendas de aplicaciones de móviles

6443605097_1bc968e672_b.jpg

 

 

Con la terminal (más eficiente y rápido):

 

 

Esta es la forma que usan la mayoría de los usuarios, simplemente es cuestión de abrir una terminal y escribir

sudo aptitude install miprogramapreferido

Como desventaja, en este metodo tenemos que adivinar el nombre del programa, si no sabemos el nombre exacto podemos buscar con

sudo aptitude search palabraclave

Para desinstalar usamos

sudo aptitude remove miprogramapreferido

Para actualizar todos nuestros programas que instalamos con el gestor de paquetes usamos dos comandos, ejecutamos el primero y cuando termina ejecutamos el segundo

sudo aptitude update

sudo aptitude upgrade

Una explicación mas extensa:

 

 

Ese comando tiene 4 palabras:

  • sudo: Indica que el comando debe ejecutarse como administrador
  • aptitude: Es el nombre del gestor de paquetes que usamos en las distribuciones derivadas de Debian, como alternativa se puede usar apt-get (son prácticamente lo mismo)
  • install: Es una orden que se le da a aptitude, queremos instalar el paquete con el nombre que escribiremos a continuación, como alternativa, para desinstalar usamos remove, para buscar, search
  • miprogramapreferido: Reemplazar por el nombre del paquete que contiene el programa a instalar

Como puse mas arriba, podemos usar apt-get como alternativa, no hay gran diferencia. No me gusta tanto apt-get porque si queremos buscar tenemos que usar

sudo apt-cache search palabraclave

Y no es lo mas intuitivo

 

Otras distribuciones usan gestores de paquetes diferentes, por ejemplo yum o pacman, pero su uso es muy similar a aptitude

 

 

 

 

 

Que pasa si el programa que quiero no está?

Los paquetes se descargan de repositorios, que son servidores que tienen los paquetes que usamos. Si el programa que queremos no está en los repositorios que tenemos configurados vamos a tener que agregar el repositorio necesario.

 

Hay repositorios que son "oficiales" o algo así como manejados por los creadores de tu distribución, puede que tengas desactivado uno de estos repositorios, no por qué hay que tenerlos a todos activados.

En el caso de Ubuntu y Linux Mint (Debian no) tenemos estos repositorios:

 

 

  • main: Software soportado oficialmente por tu distribucion
  • universe: Software soportado por la comunidad
  • restricted: Software soportado que no esta disponible en una licencia completamente libre
  • multiverse: Software que no es libre

 

 

Hay otro tipo de repositorios llamados PPA, que son algo así como repositorios personales, normalmente son repositorios que solamente tienen unos pocos programas y están generalmente mantenidos por los desarrolladores del programa, se utilizan como alternativa cuando el programa no esta en los repositorios anteriores.

 

Para saber qué repositorio necesitamos tenemos que buscar en la página web del programa en donde debería decir. También podemos probar a agregar repositorios "oficiales" de arriba.

 

Agregar repositorios "oficiales":

 

 

 

De forma gráfica (facil):

 

 

 

Una forma es entrar al gestor de paquetes o "Centro de Software" y buscar alguna opcion que permita cambiar los "Orígenes del software" o algo similar, la ventana podría ser algo como esto:

DiL3n.png

Si está difícil encontrarlo se puede probar a abrir una terminal y probar con este comando

sudo software-properties-gt

O con este

sudo software-properties-kde

Eso debería abrir una ventana como la de la imagen

 

Ubuntu tiene esta guía en inglés

 

 

 

Con la terminal (dificil):

 

 

 

Se debe agregar manualmente editando el archivo de texto /etc/apt/sources.list

Ya es más complicado, en internet deben haber tutoriales específicos para esto. En realidad es fácil, es solamente agregar unas líneas a ese archivo, el problema es saber exactamente que escribir

La ayuda de Ubuntu tiene esta guía en inglés.

 

 

 

 

 

Agregar PPAs:

 

 

 

De forma gráfica (difícil de encontrar):

 

 

 

Debe estar por ahí en el "Centro de Software", cerca de donde se agregan los repositorios "oficiales"

La verdad es que hacerlo con la terminal es tan facil que solamente dejo el link a la ayuda de Ubuntu

 

 

 

Con la terminal (fácil y rápido):

 

 

 

Hay que ejecutar el comando

sudo add-apt-repository ppa:nombredelrepositorio

O se puede agregar manualmente editando el archivo de texto /etc/apt/sources.list y agregando dos lineas:

deb http://ppa.launchpad.net/nombredelrepositorio/ppa/ubuntu versiondedistro main 
deb-src http://ppa.launchpad.net/nombredelrepositorio/ppa/ubuntu versiondedistro main

La versiondedistro es por ejemplo utopic, wily, saucy, etc. Si usas Linux Mint hay que buscar el nombre de la version de Ubuntu en la que esta basada. En Ubuntu es más fácil.

 

 

 

 

 

Instalando un archivo .deb

En vez de usar un gestor de paquetes podés instalar el paquete manualmente. Como desventaja las actualizaciones se hacen de forma manual instalando otro .deb nuevo

Es lo más parecido a Windows, el archivo .deb se puede pensar como un instalador. Siempre es recomendable usar un gestor de paquetes.

 

Al parecer Ubuntu está buscando crear un reemplazo para los .deb, llamado Snappy, de todos modos si termina implementandose se podrá seguir usando los .deb y la transición no será rápida.

Hay más tipos de "instaladores", el otro más común es .rpm, pero en Debian y derivadas (por lo tanto Ubuntu y derivadas) usamos .deb

 

Instalar de forma grafica:

 

 

 

Normalmente con hacer doble click ya basta para abrir el instalador, o puede que haya falta que hacer click derecho, "Abrir con" y seleccionar "Instalador de paquetes", "GDebi" o algo similar.

 

 

 

Instalar con la terminal:

 

 

 

Hay que abrir una terminal y ejecutar el comando

sudo dpkg -i camino/al/instalador.deb

 

 

 

Copiando el ejecutable (no recomendado):

Esto no es muy común, técnicamente no es instalar.

Es lo mismo que en Windows copiar un .exe

Como desventaja tenemos que actualizarlo manualmente

 

Una desventaja muy grande es que si queremos ver el programa en el menú de inicio tenemos que hacer el "acceso directo" o lanzador de forma manual

 

Compilando el programa (avanzado):

La ultima forma es bastante común en GNU/Linux, directamente se descarga el código fuente, que para ser ejecutado debe ser compilado

El código fuente es el programa escrito en un lenguaje entendible para las personas, luego se tiene que compilar así se obtiene el programa en un lenguaje entendible para la PC (ceros y unos!)

Olvidate de hacerlo de forma gráfica, hay que hacerlo desde la terminal.

 

El problema es que para compilar se necesitan programas que varían dependiendo que hay que compilar. Así que antes de compilar se necesitan instalar varios paquetes, el paquete indispensable es build-essentials, contiene varios programas dentro.

sudo aptitude install build-essentials

Después hay que instalar los demás paquetes que digan en las instrucciones, normalmente estos paquetes terminan en -dev (viene de development, desarrollo en ingles)

 

Para compilar varía de programa en programa, hay que buscar las intrucciones, lo más común son estos tres comandos en orden:

./configure
make
make install

Previamente hay que moverse a la carpeta del código fuente con el comando cd

 

Lo malo también es que no siempre se crean los accesos directos al menú de inicio, y para actualizar hay que compilarlo de nuevo.

Edited by Mgbu
Link to comment
Share on other sites

Esta muy bien la guia, tenemos que matizar que Ubuntu en la futura versión 16.04 cambia el sistema de paquetes a uno propio, se podrá seguir usando los deb, pero por defecto usará el nuevo sistema de paquetes.

Link to comment
Share on other sites

Ah, no sabía, estuve leyendo y está bastante raro.

Como hacen para que no haya dependencias? Por ejemplo cada programa que use GTK+ lleva su propia versión de GTK+?

 

EDIT:

Acá encontré esto

 

Dependency management
Software packages are rarely self contained -- they typically have dependencies on other packages, such as shared libraries. If a dependency is missing or incorrect, a package may not work properly or not at all.

I observed that in the Snappy example packages, all dependencies are bundled statically. For example, in the webcam-demo package, the lib/ sub folder contains the following files:

./lib/x86_64-linux-gnu/libz.so.1./lib/x86_64-linux-gnu/libc.so.6./lib/x86_64-linux-gnu/libX11.so.6./lib/x86_64-linux-gnu/libpng12.so.0./lib/x86_64-linux-gnu/libvpx.so.1..../lib/arm-linux-gnueabihf/libz.so.1./lib/arm-linux-gnueabihf/libc.so.6./lib/arm-linux-gnueabihf/libX11.so.6./lib/arm-linux-gnueabihf/libpng12.so.0./lib/arm-linux-gnueabihf/libvpx.so.1...
As can be seen in the above output, all the library dependencies, including the libraries' dependencies (even libc) are bundled into the package. When running an executable or starting a systemd job, a container (essentially an isolated/restricted environment) is composed in which the process runs (with some restrictions) where it can find its dependencies in the "common FHS locations", such as /lib.

Besides static bundling, there seems to be a primitive mechanism that provides some form of sharing. According to the packaging format specification, it also possible to declare dependencies on frameworks in the package.yaml file:

frameworks: docker, foo, bar # list of frameworks required
Frameworks are managed like ordinary packages in /app, but they specify additional required system privileges and require approval from Canonical to allow them to be redistributed.

Although it is not fully clear to me from the documentation how these dependencies are addressed, I suspect that the contents of the frameworks is made available to packages inside the containers in which they run.

Moreover, I noticed that dependencies are only addressed by their names and that they refer to the current versions of the corresponding frameworks. In the documentation, there seems to be no way (yet) to refer to other versions or variants of frameworks.

The Nix-way of managing dependencies is quite different -- Nix packages are constructed from source and the corresponding build procedures are executed in isolated environments in which only the specified build-time dependencies can be found.

Moreover, when constructing Nix packages, runtime dependencies are bound statically to executables, for example by modifying the RPATH of an ELF executable or wrapping executables in scripts that set environment variables allowing it to find its dependencies (such as CLASSPATH or PERL5LIB). A subset of the buildtime dependencies are identified by Nix as runtime dependencies by scanning for hash occurrences in the build result.

Because dependencies are statically bound to executables, there is no need to compose containers to allow executables to find them. Furthermore, they can also refer to different versions or variants of library dependencies of a package without conflicting with other package's dependencies. Sharing is also supported, because two packages can refer to the same dependency with the same hash prefix in the Nix store.

As a sidenote: with Nix you can also use a containerized approach by composing isolated environments (e.g. a chroot environment or container) in which packages can find their dependencies from common locations. A prominent Nix package that uses this approach is Steam, because it is basically a deployment tool conflicting with Nix's deployment properties. Although such an approach is also possible, it is only used in very exceptional cases.

 

Entonces es como que las dependencias van por separado de las apps. Si es así supongo que no pueden haber dependencias entre apps

Edited by Mgbu
Link to comment
Share on other sites

Ubuntu y sus cosas... además el centro de software creo que va a pasar a mejor vida, no se les dió demasiado bien, creo que la mayoría de la gente que usa Ubuntu prefiere Synaptic a pesar de ser mas feo, es mucho más util.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...