LinuxParty

NUESTRO SITIO necesita la publicidad para costear hosting y el dominio. Por favor considera deshabilitar tu AdBlock en nuestro sitio. También puedes hacernos una donación entrando en linuxparty.es, en la columna de la derecha.

Ratio: 4 / 5

Inicio activadoInicio activadoInicio activadoInicio activadoInicio desactivado
 

El principal beneficio del software libre es, como su nombre indica, el acceso al funcionamiento interno de una aplicación. Teniendo en cuenta la fuente, usted puede estudiar cómo funciona una aplicación, cambiar, mejorar y ampliar su operación, pedir prestado y reutilizar el código (por los límites de la licencia de la aplicación), y el puerto de la aplicación de plataformas nuevas y emergentes.

Sin embargo, el acceso liberal no es siempre querido. Por ejemplo, un usuario posiblemente no  desea cargar con la responsabilidad de crear y/o compilar el código. En su lugar, simplemente lo que desea, es instalar el software de un modo muy similar al tradicional "shrink-wrapped" insertarlo en el medio, configurar durante la ejecución (si procede), responder a algunas indicaciones, y listo. De hecho, para los usuarios de ordenadores, prefiere el software pre-construido. Lo que venga pre-montado es menos sensible a los caprichos del sistema y por lo tanto más uniforme y predecible.

En general, una aplicación preconstruida y de código abierto se denomina paquete y todos los paquetes incorporan archivos binarios, datos y la configuración necesaria para ejecutar la aplicación. Un paquete también incluye todos los pasos necesarios para implementar la aplicación en un sistema, normalmente en forma de una secuencia de comandos. La secuencia de comandos puede generar datos, iniciar y detener los servicios del sistema o manipular los archivos y directorios. Una secuencia de comandos también podría realizar operaciones para actualizar el software existente a una nueva versión.

Debido a que cada sistema operativo tiene su idiosincrasia, un paquete normalmente se adapta a un sistema específico. Además, cada sistema operativo proporciona su propio gestor de paquetes, una utilidad especial para agregar y quitar paquetes del sistema. Por ejemplo, los sistemas basados en Debian Linux® utilizan la Advanced Package Tool (APT), mientras que los sistemas Fedora Linux utilizan el administrador de paquetes RPM. El gestor de paquetes se opone a las instalaciones parciales y defectuosas y "desinstala" agregando y quitando los archivos en un paquete automáticamente. El gestor de paquetes también mantiene un manifiesto de todos los paquetes instalados en el sistema y puede validar la existencia de requisitos previos y prerrequisitos previamente.

Si eres un desarrollador de software o un administrador de sistemas, proporcionando la aplicación como un paquete hará las instalaciones, upgrades y el mantenimiento mucho más fácil (a los demás). Aquí, aprenderá a utilizar el popular administrador de paquetes RPM para empaquetar una utilidad. Para fines de demostración, podrá agrupar la red wget de utilidad, que descarga archivos desde Internet. La utilidad wget es útil, pero generalmente no es un  estándar entre las distribuciones. (Un análogo, curl, es a menudo incluido en las distribuciones) Tenga en cuenta que puede utilizar RPM para distribuir la mayoría de casi cualquier cosa: secuencias de comandos, documentación y datos y realizar casi cualquier tarea de mantenimiento.

Obtener wget manualmente

La utilidad de wget, como muchas otras aplicaciones de código abierto, puede hacerse en forma manual. Entendiendo que el proceso consta de cuatro pasos:

   1. Descargar y descomprimir la fuente.
   2. Generar la configuración
   3. Generar el código.
   4. Instale el software.

Puede descargar la última versión del código fuente de ftp.gnu.org wget

Listado 1. Instalando wget


	
$ tar xzf wget-latest.tar.gz
$ cd wget-1.12
$ ./configure
configure: configuring for GNU Wget 1.12
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
...
$ make
$ sudo make install

./configure consulta al sistema las opciones del configurables para el software y hardware detectado. make compila el código, y sudo make install instala el código el los directorios del sistema. por defecto los directorios del sistema serán /usr/local, tu puedes cambiarlos con el prefijo --prefix=/some/full/path/name al comando ./configure.

Para convertir este proceso en RPM, coloca el fuente en un repositorio y escribe un archivo de configuración para dictar dónde encontrar el origen a ser compilado y cómo construir e instalar el código. El archivo de configuración, denominado un archivo .spec, es la entrada a una utilidad denominada rpmbuild. El archivo de especificaciones y los binarios se empaquetarán por rpmbuild como un RPM. Cuando otro usuario descargue su RPM, la utilidad de rpm Lee el archivo especificaciones e instala el paquete por sus predefinidas instrucciones.

Antes de continuar, una advertencia. En el pasado, los paquetes fueron construidos por el superusuario root, porque era el único capaz de acceder al repositorio de código fuente del sistema de usuario. Sin embargo, este enfoque era potencialmente peligroso. Debido a que root puede modificar cualquier archivo en el sistema, era fácil alterar inadvertidamente un sistema en ejecución añadiendo archivos extraños o eliminando archivos importantes durante la generación provisional de un RPM. Recientemente, el sistema ha RPM cambiado para que cualquier usuario pueda construir RPMs en un directorio de inicio. Construir un RPM sin los privilegios de root impide realizar cambios a los archivos de sistema, o el núcleo. Aquí, se muestra el enfoque más moderno.

Para construir un RPM, primero debe:

  • Configurar una jerarquía de directorios por las especificaciones de rpmbuild.   
  • Colocar el código fuente y los archivos adicionales en las ubicaciones adecuadas en la jerarquía.
  • Crear su archivo spec.
  • Construir el RPM. Opcionalmente, puede crear una fuente RPM para compartir el código fuente con otros usuarios.

Para, cree la jerarquía de directorios en un directorio dentro de su HOME. por ejemplo: $HOME/mywget y cree estos 5 subdirectorios

  • BUILD. BUILD se utiliza como espacio de memoria virtual para compilar realmente el software.
  • RPMS. RPMS contiene el binario RPM creado por rpmbuild (si todo fue bien)
  • SOURCES. SOURCES es para el código fuente.
  • SPECS. SPECS contendrá el fichichero de especificaciones spec o más de uno.
  • SRPMS. SRPMS Contendrá el source RPM creado durante el proceso


Como minimo, debe colocar el codigo fuente en SOURCES y el fichero spec en SPECS.

Copiar su origen, idealmente incluido como un tarball, en el directorio de fuentes SOURCES, como se muestra en el listado 2. Si es necesario, cambie el nombre del tarball para incluir el número de versión de la aplicación para diferenciarlo de otros. La Convención de nomenclatura es paquete-version.tar.gz. En el caso de wget, utilice:


Listado 2. Copiando sus fuentes


$ cd ~
$ mkdir mywget
$ cd mywget 
$ mkdir BUILD RPMS SOURCES SPECS SRPMS
$ cd SOURCES
$ cp wget-latest.tar.gz .
$ mv wget-latest.tar.gz wget-1.12.tar.gz
$ cd ..

A continuación, cree el archivo spec. Un archivo spec no es más que un archivo de texto con una sintaxis especial. El listado 3, muestra un ejemplo de un archivo spec.


Listado 3. Ejemplo de fichero spec


	
# This is a sample spec file for wget
%define _topdir	 	/home/strike/mywget
%define name			wget 
%define release		1
%define version 	1.12
%define buildroot %{_topdir}/%{name}-%{version}-root
BuildRoot:	%{buildroot}
Summary: 		GNU wget
License: 		GPL
Name: 			%{name}
Version: 		%{version}
Release: 		%{release}
Source: 		%{name}-%{version}.tar.gz
Prefix: 		/usr
Group: 			Development/Tools
%description
The GNU wget program downloads files from the Internet using the command-line.
%prep
%setup -q
%build
./configure
make
%install
make install prefix=$RPM_BUILD_ROOT/usr
%files
%defattr(-,root,root)
/usr/local/bin/wget
%doc %attr(0444,root,root) /usr/local/share/man/man1/wget.1


Analicemos el archivo spec de arriba a abajo. Líneas 1-5 definen un conjunto de variables de conveniencia utilizadas en el resto del archivo. Líneas de 7-15 son el número de parámetros necesarios mediante el parámetro de formulario: valor. Como puede ver en la línea 7 y en otros lugares, variables pueden evaluar y combinadas para producir el valor de una configuración.

Vamos a caminar a través del fichero de especificaciones de arriba a abajo. Líneas 1-5 definir un conjunto de variables de conveniencia utilizada en el resto del archivo. Líneas 7-15 establece el número de parámetros necesarios utilizando la forma: parameter: value. Como se puede ver en la línea 7 y en otros lugares, las variables pueden ser evaluados y combinarse.

Los nombres de parámetro son en gran medida evidentes, pero BuildRoot merece algunas explicaciones para diferenciarlo del directorio de la construcción que ya creado. BuildRoot es un proxy para el directorio de instalación final. En otras palabras, si wget en última instancia está instalado en /usr/local/bin/wget y otros subdirectorios de /usr/local, tales como /usr/local/man para la documentación, BuildRoot significa que usará /usr/local durante el proceso de construcción del RPM. Una vez que ajuste BuildRoot, puede acceder a su valor mediante la variable de entorno RPM_BUILD_ROOT. Siempre debe establecer BuildRoot en su archivo de especificaciones y comprobar el contenido de ese directorio para comprobar lo que va a ser instalado por el paquete.

Aquí están algunos consejos:

  • No use  ./configure --prefix=$RPM_BUILD_ROOT. Este comando se basa en todo el paquete, en el supuesto de que la ubicación final fuera la raíz. Es probable que esto causaría que cualquier programa que necesiten localizar sus archivos de instalación durante el tiempo de ejecución, fallaría, porque cuando el RPM es finalmente instalado en el sistema del usuario, los archivos no están bajo la raíz ya que sólo es un directorio temporal en su sistema de construcción.
  • No incluya una ruta en la definición de la Fuente.
  • La versión y lanzamiento son especialmente importantes. Cada vez que cambie el código de la aplicación o los datos y deberá hacer un nuevo RPM disponible, asegúrese del incremento de los valores de la versión y la versión para reflejar los cambios mayores y menores, respectivamente.

Puede ser útil para volcar el número de versión cada vez que cree un RPM, aunque para su propio uso, mantenga los intentos por separado.

La siguiente sección se inicia con la %description. Usted debe proporcionar una descripción concisa pero clara del software aquí. Esta línea se muestra cada vez que un usuario ejecute rpm -qi para consultar la base de datos RPM. Usted puede explicar lo que el paquete es, describa advertencias o instrucciones adicionales de configuración, y mucho más.

Las secciones: %prep, %build, e %install que están al lado, en forma consecutiva. Cada sección genera un script de shell que está incrustado en el RPM y se ejecuta posteriormente como parte de la instalación. %prep prepara el código fuente, como descomprimir el archivo tar. Aquí, %setup-q es una macro %prep para desempaquetar el archivo tar de forma automática

Las instrucciones de la sección %build deberían serle familiar. Son idénticos a los pasos que utiliza para configurar y poner en marcha la construcción de forma manual. La sección de %install es idéntico, también. Sin embargo, mientras que el objetivo del manual de construcción fue el real /usr/local de la guía de su sistema, el objetivo de la instrucción de %install es ~/mywget/BUILD.

%files lista de los archivos que deben estar incluido en el RPM y, opcionalmente, establece los permisos y otra información. Dentro %files, puede utilizar la macro %defattr para definir los permisos por defecto, el propietario y grupo de archivos del RPM, en este ejemplo,%defattr (-, root, root) instala todos los archivos como propiedad de root, con lo los permisos que se encuentran los paquetes RPM, cuando este se creó

Puede incluir varios archivos por línea en %files. Puede etiquetar los archivos de documentación mediante la adición de %doc o mediante %config a la línea. %doc le dirá a RPM que el archivo es un archivo de documentación, de modo que si un usuario instala el paquete utilizando - excludedocs, el archivo no debería instalarlos. %config le dirá a RPM que se trata de un archivo de configuración. Durante las actualizaciones, RPM intentará evitar sobrescribir la configuración cuidadosamente modificada por un usuario con un archivo empaquetado en RPM

Tenga en cuenta que si usted anota el nombre del directorio en %files, RPM incluye todos los ficheros por bajo de ese directorio.

Acelerando RPM:

Ahora que los archivos están en su lugar y su archivo de especificación está definido, está listo para construir el actual archivo RPM. Para construirlo, utilice la utilidad llamada rpmbuild:


$ rpmbuild -v -bb --clean SPECS/wget.spec


Este comando utiliza el archivo de especificaciones (-bb) para construir un paquete binario con salida detallada (-v). La utilidad elimina el árbol de construcción después de crear el paquete (-clean). Si usted también quiere construir el RPM fuente, deberá indicar ( -ba ) ("construir todos")  (Vea la página man rpm para obtener una lista completa de opciones.)

rpmbuild realiza estos pasos:

    * Lee y analiza el archivo wget.spec.
    * Ejecuta la sección %prep para desempaquetar el código fuente en un directorio temporal. Aquí, el directorio temporal es BUILD.
    * Ejecuta la sección %build para compilar el código.
    * Ejecuta la sección %install para instalar el código de los directorios en el equipo de generación.
    * Lee la lista de archivos de la sección de %files, los empaqueta, y crea un RPM binario (y los archivos fuente RPM, si usted quiere).

Si usted examina su directorio $HOME/mywget, tendrá que buscar un nuevo directorio llamado  wget-1.12-root.. Este directorio es el proxy para el punto de destino. También debe encontrar un nuevo directorio llamado RPMS/i386, que a su vez debería contener su RPM, llamado wget-1.12-1.i386.rpm. El nombre del RPM refleja que se trata de la versión 1.12 wget para el procesador i386.

Para comprobar que el RPM contiene los archivos adecuados, puede utilizar el comando rpm, como se muestra en el Listado 4.

Listado 4. Verificando el contenido del rpm

	
$ rpm -Vp RPMS/i386/wget-1.12-1.i386.rpm
missing     /usr/local/bin/wget
.M....G.    /usr/local/etc
missing   c /usr/local/etc/wgetrc
.M....G.    /usr/local/share
missing     /usr/local/share/info
missing   d /usr/local/share/info/wget.info
missing     /usr/local/share/locale
missing     /usr/local/share/locale/be
missing     /usr/local/share/locale/be/LC_MESSAGES
missing   d /usr/local/share/locale/be/LC_MESSAGES/wget.mo
. 


El comando rpm -Vp RPMS/i386/wget-1.12-1.i386.rpm verifica el paquete contenga los archivos. A pesar de que aparentemente muestre un montón de errores (principalmente, por que no está instalado, lo acabas de crear), cada uno es un indicio de que el contenido del archivo RPM correcto. Si usted está esperando un archivo y no aparece en la salida, es que no ha sido incluido en el paquete. En ese caso, revisar el archivo de especificaciones y asegurarse de que el archivo se nombra en la sección %files

Una vez que haya verificado la RPM, puede distribuir el archivo a compañeros o tal vez entre sus colegas, que debe deberán ejecutar el comando rpm para instalar wget en sus propios sistemas:

$ sudo rpm -i wget-1.12-1.i386.rpm


No estás registrado para postear comentarios



Redes:



   

 

Suscribete / Newsletter

Suscribete a nuestras Newsletter y periódicamente recibirás un resumen de las noticias publicadas.

Donar a LinuxParty

Probablemente te niegues, pero.. ¿Podrías ayudarnos con una donación?


Tutorial de Linux

Formulario de acceso

Filtro por Categorías