Hola, vamos a continuar el tutorial sobre cómo crear paquetes RPM que empecé el otro día, si me lees te advierto que antes leas la primera parte de este tutorial si no lo hiciste antes.
Bien, en esta segunda parte trataré de explicar cómo crear un paquete rpm de un programa del cual no poseemos sus fuentes.
Recordar antes que en el mundo rpm lo de fuentes es referirnos a que el programa a empaquetar no posee el paquete en formato src-rpm, en cuyo interior se encuentra el fichero de extensión spec; lo cual nos obliga a crearlo por nuestra cuenta.
La explicación se basará mediante un ejemplo concreto, me basaré sobre el programa VerTV de nuestro coleguilla Alberto.
El primer paso será obtener el programa a empaquetar en formato comprimido, es fuertemente recomendable que esté comprimido en formato .tar.bz2, así que si no lo está lo podemos cambiar fácilmente con una simple descompresión y volviendo a comprimir en dicho formato, lo podéis realizar con un patr de clicks sin tener que aplicar ningún comando por terminal, al estilo ventanas Si queréis os podéis bajar el programa de AQUI, para hacer una práctica interactiva.
Detengámonos un suspiro en este punto para aclarar una cosa, si abrís el comprimido de VerTV notaréis que si intentamos instalarlo directamente no podemos hacerlo mediante la típica compilación del programa ya que no figuran los ficheros correspondientes. Hasta el momento yo conozco tres formas de hacer esta compilación:

1. Mediante Autotools-> Con configure y make
2. Mediante la forma cmake
3. Mediante Scons-> Es una herramienta similar a autotools

Otra forma sería que el programa fuese de codigo python y llevase un fichero instalador, pero esto ya escapa de este ámbito explicativo. Hasta aquí este pequeño inciso para aclarar a qué me refiero cuando en el título he escrito lo de “Sin Autotools”.
Bien, nuestro programa VerTV no lleva autotools y, por tanto, deberemos tenerlo muy en cuenta para crear el fichero spec que os explico en breve.
Bueno si has leido mi primera parte del tutorial recordarás quie en nuestro directorio ppal. creamos un directorio raíz llamado rpm con una serie de subdirectorios, de esos directorios hay uno que se llama SOURCES, dentro de dicho directorio debéis meter el fichero .tar.bz2 de vuestro programa, ¡sin descomprimirlo!. En nuestro ejemplo concreto se llama vertv-1.0.1.tar.bz2; ya tenemos otro paso superado
El siguiente peldaño será crear el fichero .spec, este paso es el más dificultoso e importante de todo el proceso. Os pongo primero como guía el de nuestro ejemplo y os voy explicando lo más importante. Al fichero le he llamado vertv.spec, debéis guardarlo en la ruta rpm/SPECS, y se puede escribir con gedit, kate o el que más os mole. Aquí tenéis el mio:

Name: vertv
Version: 1.0.1
Release: 1
URL: http://diariodeunlinux3ro.es/
Summary: Front-end para Sopcast
License: GPL
Group: Internet/Remote Access
Source0: vertv-1.0.1.tar.bz2
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
Requires: zenity >= 2.20, totem >= 2.18, mplayer >= 0.99, vlc >= 0.8.0, libstdc++5-devel, libstdc++5, glibc, gcc, libgcc1
Provides: %{name}, ld-linux.so.2(GLIBC_PRIVATE),libc.so.6(GLIBC_PRIVATE)

%description
VerTV es un front-end realizado por Alberto Jimenez (http://diariodeunlinux3ro.es) mediante zenity gracias al cual podremos visualizar vídeos de Sopcast. El objetivo de este proyecto es construir una interfaz potente y bonita, aunque zenity no sea muy apropiado para ello. Sin embargo, zenity hace que sea muy intuitivo el manejo del programa.

Más información en: http://diariodeunlinux3ro.es

%prep
%setup -q -a 0

%install
rm -rf $RPM_BUILD_ROOT
install -D -m 755 vertv.sh $RPM_BUILD_ROOT/usr/bin/vertv.sh
install -D -m 755 sp-sc-auth $RPM_BUILD_ROOT/usr/bin/sp-auth/sp-sc-auth
install -D -m 644 vertv.desktop $RPM_BUILD_ROOT/usr/share/applications/vertv.desktop
install -D -m 644 vertv.png $RPM_BUILD_ROOT/usr/share/pixmaps/vertv.png
install -D -m 755 postinst $RPM_BUILD_ROOT/usr/bin/sp-auth/postinst

%clean
rm -rf $RPM_BUILD_ROOT

%post
sh /usr/bin/sp-auth/postinst
rm -f /usr/bin/sp-auth/postinst

%files
%defattr(0755,root,root)
/usr/bin/vertv.sh
/usr/bin/sp-auth/sp-sc-auth
/usr/share/applications/vertv.desktop
/usr/share/pixmaps/vertv.png
/usr/bin/sp-auth/postinst

%changelog
* Mon Sep 22 2008 Cristobal Lopez <http://tobal.cymaho.com>
- Modificando el fichero spec
- Construir el rpm sin ser superusuario
* Wed Sep 17 2008 Alejandro Sanchez <http://sinwindows.es>
- Primer fichero spec
- Conseguido que pregunte por la dependencia de Zenity
- Contiene lo mismo que el .deb creado por Alberto

Bien, no os asustéis que no es muy difícil. Vamos con la explicación de un primer bloque:

Name: vertv
Version: 1.0.1
Release: 1
URL: http://diariodeunlinux3ro.es/
Summary: Front-end para Sopcast
License: GPL
Group: Internet/Remote Access

En Name y Version ponemos el nombre del programa y la versión a empaquetar, en Realease ponemos el número de la versión del rpm que vamos a crear, normalmente será 1, pero si hacemos cambios en el rpm y no afectan a la versión del programa a empaquetar, el número será mayor que 1.
En URL ponemos la web de donde nos hayamos bajado el programa, en Summary ponemos en una línea de qué va el programa, ¡sin acentos!. En License ponemos la licencia del programa, en Group ponemos la sección a la que corresponde nuestro programa cuando aparezca en Rpmdrake, en el caso de Mandriva.
Pasemos a un segundo bloque:

Source0: vertv-1.0.1.tar.bz2
BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot
Requires: zenity >= 2.20, totem >= 2.18, mplayer >= 0.99, vlc >= 0.8.0, libstdc++5-devel, libstdc++5, glibc, gcc, libgcc1
Provides: %{name}, ld-linux.so.2(GLIBC_PRIVATE),libc.so.6(GLIBC_PRIVATE)

%description
VerTV es un front-end realizado por Alberto Jimenez (http://diariodeunlinux3ro.es) mediante zenity gracias al cual podremos visualizar vídeos de Sopcast. El objetivo de este proyecto es construir una interfaz potente y bonita, aunque zenity no sea muy apropiado para ello. Sin embargo, zenity hace que sea muy intuitivo el manejo del programa.

Más información en: http://diariodeunlinux3ro.es

En Source0 ponemos el nombre del comprimido que hemos puesto en el directorio SPECS. Si tuviésemos más ficheros en SOURCES que estuviesen relacionados con el programa añadiríamos Source1, Source2,…. hasta tenerlos todos. Aquí en los manuales que he leido recomiendan que pongáis la web, pero yo no os lo recomiendo si la web es muy larga y con símbolos raros, porque os dará error de sintaxis.
En BuidRoot os aconsejo que lo pongáis como está, su función es especificar que en /rpm/tmp se realizarán las operaciones necesarias de construcción del paquete rpm sin permisos de superusuario para no dañar nuestro sistema.
En Requires escribiremos las dependencias necesarias para que nuestro programa funcione, junto con la versión mínima de cada dependencia. Podemos añadir secciones como Suggests o Conflicts
La sección Provides se utiliza para especificar qué cosas extras provee nuestro programa, esto normalmente no deberéis ponerlo, lo que pasa es que este programa daba problemas con ciertas macros de C y se tuvo que hacer una triquiñuela, que solucionó Sin Windows.
En %description añadiremos una descripción más larga del programa y sin acentos.
Si habéis debianizado alguna vez un programa podréis discernir que hasta aquí se puede corresponder en un 99 % al fichero control de Debian. Pasemo a otro bloque:

%prep
%setup -q -a 0

Esto es un script en el cual lo que se hará es descomprimir el .tar.bz2 de nuestro programa en /rpm/BUILD y dejarlo todo preparado para la consrucción. Esto lo conseguimos con setup, con la opción -q nos lo descomprimirá de forma silenciosa, el 0 indica que lo haga con el Source0 que especificamos anteriormente, si tenemos más sources los especificamos aquí.

%install
rm -rf $RPM_BUILD_ROOT
install -D -m 755 vertv.sh $RPM_BUILD_ROOT/usr/bin/vertv.sh
install -D -m 755 sp-sc-auth $RPM_BUILD_ROOT/usr/bin/sp-auth/sp-sc-auth
install -D -m 644 vertv.desktop $RPM_BUILD_ROOT/usr/share/applications/vertv.desktop
install -D -m 644 vertv.png $RPM_BUILD_ROOT/usr/share/pixmaps/vertv.png
install -D -m 755 postinst $RPM_BUILD_ROOT/usr/bin/sp-auth/postinst

En la sección install especificamos dónde se instalarán nuestros ficheros del programa a empaquetar, lo haremos con el comando install, por ejemplo:

%install
install -D -m 755 vertv.sh $RPM_BUILD_ROOT/usr/bin/vertv.sh

Lo que hará es indicar que el fichero vertv.sh se copiará/instalará en /usr/bin con permisos 755, de ejecución, creando los directorios que falten gracias a -D. Normalmente los permisos serán 644, y sólo pondremos permisos 755 a los que sean ejecutables. Es obligado introducir la macro $RPM_BUILD_ROOT para que sepa que será root. Podéis consultar sobre install mediante la terminal escribiendo man install.
Si no queréis hacerlo con install lo podéis hacer con mkdir y cp, pero os aconsejo hacerlo con install porque es como se hace normalmente en los ficheros make de autotools, ya que nos facilita lo de especificar los permisos.
Recalco que esto debemos hacerlo sólo en aquellos programas que no lleven autotools, en los demás veréis que es mucho más sencillo en una próxima entrega
La línea rm -rf $RPM_BUILD_ROOT es aconsejable ponerla para limpiar anteriores empaquetamientos, para ser más limpios.

%clean
rm -rf $RPM_BUILD_ROOT

Este código creo que esta claro lo que hace

%post
sh /usr/bin/sp-auth/postinst
rm -f /usr/bin/sp-auth/postinst

Bien, esta sección de post no es frecuente añadirla, consiste en que cuando instalemos el rpm si hay que hacer alguna tarea posterior indicarle cuál hacer, en este caso se requiere que se ejecute el fichero postinst y luego se borre, no voy a explicar mucho más de ello, es un tema avanzado y que podéis obviar.

%files
%defattr(0755,root,root)
/usr/bin/vertv.sh
/usr/bin/sp-auth/sp-sc-auth
/usr/share/applications/vertv.desktop
/usr/share/pixmaps/vertv.png
/usr/bin/sp-auth/postinst

Esta sección sirve para definir los atributos de nuestros ficheros del programa y hacer un listado de los ficheros que compondrán el paquete, se deben listar todos con su ruta, es bastante coñazo, nos podemos ayudar con el comando rpm -bi mipaquete.spec para un listado.

%changelog
* Mon Sep 22 2008 Cristobal Lopez <http://tobal.cymaho.com>
- Modificando el fichero spec
- Construir el rpm sin ser superusuario
* Wed Sep 17 2008 Alejandro Sanchez <http://sinwindows.es>
- Primer fichero spec
- Conseguido que pregunte por la dependencia de Zenity
- Contiene lo mismo que el .deb creado por Alberto

Esta sección no tiene nada de especial, tan sólo es una especie de diario sobre los distintos cambios realizados en el programa o paquete rpm, tan sólo debemos respetar la estructura para no tener fallos de escritura.
Con esto tenemos explicado el fichero .spec, como véis es un poco fastidioso, sobretodo cuando no lo tenemos hecho por alguien, es decir, no tenemos las fuentes, pero os aseguro que esto es la menor de las veces. Quisiera hacer notar que hay muchas formas de hacer el spec, yo he puesto un standard, no he puesto cómo añadir parches u otras cosas. Os recomiendo que os bajéis las fuentes de otros programas para aprender más del asunto.
Bueno llegamos al final del proceso, sólo nos queda crear el paquete con rpmbuild así:

cd rpm
cd SPECS
rpmbuild -ba --target noarch vertv.spec

La opción -ba especifica que construya el paquete y el paquete fuente src-rpm del programa, le hemos añadido en éste caso la opción –target noarch para aclarar que nuestro programa sirve para cualquier procesador. Si queremos firmar el paquete debemos añadir la opción –sign.
Si todo ha ido bien podéis encontrar vuestros paquetes en /rpm/RPMS y /rpm/SRPMS listos para probarlos y compartirlos.
Y hasta aquí esta segunda parte del tutorial #:-S
Fuente -> Construir RPM en la Wikipedia

Saludos :-h

Hola, voy a escribir unos tres artículos sobre cómo crear paquetes RPM por nuestra cuenta. Llevo tiempo queriendo escribir sobre ello pero no encontré ninguna explicación de cómo crear paquetes RPM de programas que no contienen autotools, hasta que Alejandro de Sin Windows habló de cómo hacerlo.
Trataré de cómo crear dichos paquetes sin poner en riesgo nuestro sistema linuxero, es decir, sin ser superusuario, ya que corremos el riesgo de si lo hacemos como superusuario de instalar el paquete que estamos haciendo el RPM al mismo tiempo que lo creamos, y claro; si nos hemos equivocado gravemente al crearlo y el paquete afecta a configuraciones importantes del sistema podría hacernos un verdadero estropicio.

Pero empecemos por el principio, seguramente muchos os estaréis preguntando qué puñetas es eso del RPM; pues es muy sencillo. Para poder instalar un programa con tan sólo un doble click de ratón sobre un instalador en distribuciones linuxeras basadas en RedHat (como Mandriva, Suse o la propia RedHat, entre otras) necesitaremos empaquetar todo el programa en un paquete que llevará como extensión el sufijo rpm, así, si nuestro programa se llama programita, el paquete se llamará programita.rpm.
Para los de Debian o los ubunteros rpm es el equivalente al deb de Debian, o a los instaladores tipo Setup.exe para los windowseros.
Vale, una vez sabido que nuestro objetivo es empaquetar un programa en formato RPM para que cualquiera pueda instalarlo con un doble click de ratón (y también desinstalarlo), veamos los pasos previos a realizar.
Lo primero será instalar los programas necesarios para poder crearlos, que son:

rpm, rpm-build, spec-helper, libtool, rpmlint

Todos estos programas los podéis instalar fácilmente desde vuestro gestor de instalación. Ahora vamos a crear una serie de directorios en nuestra carpeta personal los cuales nos permitirán poder crear nuestros RPM sin ser superusuarios. Os pongo primero el comando y os explico, así que abrid terminal y escribid

 mkdir -p ~/rpm/{BUILD,BUILDROOT,RPMS/i586,RPMS/noarch,RPMS/i686,SOURCES,SRPMS,SPECS,tmp}

Bien, la orden nos va a crear en nuestro home un directorio raíz llamado rpm, del cual se desprenderán unos subdirectorios con la estructura siguiente:

|-- BUILD
|-- RPMS
|   |-- i586
|   `-- noarch
|-- SOURCES
|-- SPECS
|-- SRPMS
`-- tmp

Vale, de esos directorios empiezo explicando el SOURCES, en este directorio ubicaremos nuestro programa, aquí lo que colocamos es el programa con sus fuentes que nos bajamos para poderlo compilar e instalar con autotools, o aquellos programas que no hacen falta compilarlos para ejecutarlos porque ya vienen los binarios. Ambos tipos deberemos colocarlos ahí de forma comprimida y en formato .tar.bz2. Si tenemos más fuentes las pondremos también ahí. No os preocupéis si estáis algo confusos, en el siguiente artículo lo entenderéis mejor.
En dicho directorio también deberemos colocar los parches si los hubiera, pero esto es un tema demasiado avanzado para lo que yo quiero explicar y entiendo todavía.
El directorio SPECS es un directorio en el cual deberemos ubicar nuestro fichero de extensión .spec de nuestro programa a empaquetar, dicho fichero lo podemos crear con gedit o kate. Contendrá cosas como el nombre del programa, su versión, arquitectura, descripción del programa, dependencias y cómo hay que proceder a su instalación. El fichero spec es como el fichero control de Debian pero al que además le añadimos una serie de instrucciones especificando cómo instalar, vamos que lleva también una especie de órdenes al estilo del fichero rules de DEBIAN. La creación de este fichero es la parte más delicada y compleja de todo el proceso, al principio es bastante tedioso y complejo, pero conforme vas haciendo más paquetes va resultando más claro; ya os explicaré
El directorio BUILD y el directorio tmp son directorios con los que trabajará el ordenador cuando ejecutemos la orden de creación del rpm mediante el comando rpmbuild, y son los que nos permiten no tener que hacerlo como superusuario.
El directorio RPMS es el directorio donde se guardará nuestro paquete creado al final del proceso, según la arquitectura en que lo hayamos creado se nos guardará en su respectivo subdirectorio: i686, 64bits, etc El de noarch es para aquellos paquetes que pueden ser instalados en cualquier arquitectura, equivalen al ALL de Debian.
El directorio SRPMS es el directorio nuestro paquete rpm pero en su estilo de fuentes. Me explico, cuando creamos el rpm tenemos la opción de crear un rpm de fuentes que llevará en su nombre el identificativo src.rpm, así para nuestro programita sería programita-1.0.src.rpm. Estos paquetes lo que llevan son el código fuente del programa y el fichero .spec. Y sirven para poder crear una nueva versión del programa a partir de este rpm de fuentes, es muy útil porque así no tenemos que crear de cero el fichero spec.
Sí quisiera aclarar que aquí cuando me refiero a las fuentes del programa no me refiero sólo al típico fichero comprimido de un programa que viene con las herramientas típicas de compilación e instalación de autotools o scons, sino que también puede ser un comprimido del programa con los ejecutables o binarios. Es decir, que en este contexto igual son fichero fuentes el bajarme el comprimido del navegador Flock el cual para su instalación basta con descomprimirlo; como el comprimido del GIMP que para instalarlo deberíamos compilarlo con lo de configure, make y make install. Espero que esto os quede claro, porque es muy importantge entenderlo.
Bien, ya nos queda poco para terminar los preparativos, tan sólo nos falta crear un archivo oculto en nuestro directorio personal, le llamaremos .rpmmacros ( ¡NO OS OLVIDÉIS DE ANTEPONER EL PUNTO PARA QUE SEA OCULTO!!! ), lo podéis crear con un editor de textos, os pongo uno de ejemplo:

%_topdir %(echo $HOME)/rpm
%_tmppath %(echo $HOME)/rpm/tmp
# Si desea que sus paquetes sean automáticamente firmados con GPG, añada estas
# tres líneas cambiando 'Mandrivalinux' por su nombre GPG. Tambien puede usar
# rpm resign para firmarlos posteriormente.
%_signature gpg
%_gpg_name tobal
%_gpg_path ~/.gnupg
# Agregue su nombre y dirección de correo electrónico en el campo %packager.
# Puede que tambien desee cambiar 'vendor' por usted mismo.
%packager TuNombre Apellido
%distribution Mandriva Linux
%vendor Mandriva
# Si desea que sus paquetes tengan su propio sufijo de distribución en lugar
# de mdv, anótelo aquí
%distsuffix tobal_mdv

Bien, cómo véis es sencillo de hacer, cambiad lo de tobal por vuestro nombre de usuario, y rellenad vuestro e-mail y nombre donde corresponda. Si estáis en Suse pues ya sabéis que debéis cambiar Mandriva por Suse y mdv por lo que toque
En ese texto veréis tres líneas que son:
%_signature gpg
%_gpg_name tobal
%_gpg_path ~/.gnupg

Bien, estas tres líneas sirven para que podáis firmar vuestros paquetes, me explico, si es el caso que queréis crearos un repositorio de Mandriva será conveniente que vuestro repositorio tenga una firma de clave, para poder autenticar vuestro repositorio. De esas tres líneas sólo hace faltga que cambiéis donde pone tobal por el nombre que le hayáis dado a vuestra clave. Para crear la clave se hace mediante terminal con la orden gpg, os pongo mi salida por terminal:

$ gpg --gen-key
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directorio `/home/tobal/.gnupg' creado
gpg: creado un nuevo fichero de configuración `/home/tobal/.gnupg/gpg.conf'
gpg: AVISO: las opciones en `/home/tobal/.gnupg/gpg.conf' no están aún activas en esta ejecución
gpg: anillo `/home/tobal/.gnupg/secring.gpg' creado
gpg: anillo `/home/tobal/.gnupg/pubring.gpg' creado
Por favor seleccione tipo de clave deseado:
   (1) DSA y ElGamal (por defecto)
   (2) DSA (sólo firmar)
   (5) RSA (sólo firmar)
Su elección: 1
El par de claves DSA tendrá 1024 bits.
las claves ELG-E pueden tener entre 1024 y 4096 bits de longitud.
¿De qué tamaño quiere la clave? (2048)
El tamaño requerido es de 2048 bits
Por favor, especifique el período de validez de la clave.
         0 = la clave nunca caduca
        = la clave caduca en n días
      w = la clave caduca en n semanas
      m = la clave caduca en n meses
      y = la clave caduca en n años
¿Validez de la clave (0)?
La clave nunca caduca
¿Es correcto? (s/n) s

Necesita un identificador de usuario para identificar su clave. El programa
construye el identificador a partir del Nombre Real, Comentario y Dirección
de Correo Electrónico de esta forma:
    "Heinrich Heine (Der Dichter) "

Nombre y apellidos: tobal
Dirección de correo electrónico: lopeztobal@gmail.com
Comentario:
Ha seleccionado este ID de usuario:
    "tobal "

¿Cambia (N)ombre, (C)omentario, (D)irección o (V)ale/(S)alir? v
Necesita una frase contraseña para proteger su clave secreta.
$ gpg --list-keys
/home/tobal/.gnupg/pubring.gpg
------------------------------
pub   1024D/F47BFB7C 2008-09-23
uid                  tobal
sub   2048g/8C3E538B 2008-09-23

Como podéis apreciar es bastante sencillo crear una clave pública para un repositorio, acordaos de apuntaros vuestra frase secreta en un papel porque cuando construyáis el paquete os la preguntará. En lo de la clave falta un pequeño detalle, es exportarla a un fichero de extensión .gpg para que todo el mundo tenga acceso a ella, tan sencillo como abrir terminal y escribir:

$ gpg --export -a 'tobal' > RPM-GPG-tobal.gpg

Ahora si váis a vuestro directorio personal encontraréis el fichero gpg, en mi caso es RPM-GPG-tobal.gpg; ya listo para subirlo al repositorio Fijaros que en el fichero .rpmmacros en el nombre de gpg he puesto el mismo que en la generación de la clave, en mi caso es tobal.
Deciros, que esta forma de crear la clave es independiente de la distribución en la que estéis, esta forma de hacerla también sirve para distribuciones DEBIAN, así que para un repositorio propio basado en DEBIAN podemos crear así la clave. En lo único que cambia es en la forma de introducir el comando para construir el paquete con la firma de la clave pública. Cuando vayamos a crear el paquete rpm lo crearemos con la orden rpmbuild y la opción sign. Para que os aclaréis y como pequeño adelanto, supongamos que nuestro programa se llama programita, entonces la orden de construcción será:

rpmbuild -ba --sign programita.spec

No os preocupéis que ya os explicaré todo esto con un ejemplo concreto en el próximo artículo.
Sólo falta aclarar que el gpg y el md5sums no son la misma cosa, así que un mismo paquete puede llevar ambos, uno de ellos o ninguno; pero ambos sirven para autenticar paquetes. Obviamente lo del gpg no hace falta hacerlo si el rpm no lo vais a subir a un repositorio firmado.
Naturalmente todo lo que he explicado en el artículo, o el 99% de lo que he escrito, sólo hay que hacerlo una vez
Y bueno hasta aquí esta primera parte sobre las tres que tengo programadas sobre cómo crear paquetes RPM, uuff cuesta montón escribirlo todo #:-S Bueno qué, ¿nos vemos en las siguientes entregas o ya os habéis acojonado?
Saludos :-h
Fuente 1 -> Sin Windows
Fuente 2 -> Artículo en BlogDrake
Fuente 3 -> Artículo en la Wiki De Mandriva