== Semana del desarrollador ==

Martes 31 de Enero del 2012 - Lo que se tiene y no se debe hacer al empaquetar software -- SpamapS 
{{{#!IRC
01:06 < chilicuil> la proxima platica 'Lo que se tiene y no se debe hacer al empaquetar software' sera
impartida por SpamapS
01:06 < chilicuil> durara media hr y promete mucho
01:06 < chilicuil> comenzare la interpretacion ahora
01:07 < chilicuil> hola y bienvenidos, aspirantes, y potenciales desarrolladores!
01:08 < chilicuil> la razon por la cual decidi hacer esta corta presentacion es diseminar algunos puntos
importantes sobre el empaquetado cuando se trabaja en Ubuntu
01:08 < chilicuil> y cuando se reportan hacia Debian
01:09 < chilicuil> algunos de estos puntos, se basan en mi opinion personal, otros son formas generalizadas
de trabajar en Ubuntu y pueden no ser del todo compatibles
01:09 < chilicuil> con las politicas establecidas para cada paquete en Debian/Ubuntu
01:09 < chilicuil> tengan en cuenta esto cuando apliquen los tips
01:10 < chilicuil> antes de comenzar, tendran que haber leido http://wiki.debian.org/IntroDebianPackaging ,
es una lectura necesaria si pretenden empaquetar software para Ubuntu/Debian
01:11 < chilicuil> tambien recomiendo la lectura de http://wiki.debian.org/mk-sbuild
01:11 < chilicuil> una vez teniendo esto, pasemos a las cosas que NO deben hacerse:
01:11 < chilicuil> - entrar en panico
01:12 < chilicuil> - usar CDBS en paquetes que no tienen sistema de parches predefinido
01:12 < chilicuil> - usar dpatch (o cualquier otro diferente a quilt)
01:13 < chilicuil> - crear reglas en debian/rules demasiado complicadas
01:14 < chilicuil> CDBS es una forma antigua de crear paquetes, en esta se incluyen reglas
hyper-generalizadas del Makefile y despues se crean variables para cambiar la manera de crearlo, estaras
mejor si usas debhelper
01:15 < chilicuil> pronto te daras cuenta que usar 'dh_make' para crear un paquete, independientemente de
la manera que se construya, es una forma segura y practica
01:17 < chilicuil> dpatch es un sistema de paquetes que ha pasado a sido reemplazado por quilt, un sistema
de parches se supone que sirve para mantener en orden la lista de parches, y para mantenerlo separado
del codigo de upstream facilmente
01:17 < chilicuil> se esta trabajando para que bzr soporte 'looms', de tal forma que quilt tampoco
seria necesario, pero no se hasta que punto se pueda usar
01:18 < chilicuil> no usen svn, ni mucho menos cvs para llevar el control de sus cambios, utilicen git,
hg o bzr para ello
01:19 < chilicuil> ahora, una pequeña lista de cosas que DEBERIAN hacer:
01:19 < chilicuil> - utilizar dh_make
01:19 < chilicuil> - usar quilt
01:19 < chilicuil> - utilizar git, bzr o hg para mantener la lista de cambios
01:20 < chilicuil> - utilizar udd (bzr + launchpad) para paquetes especificos de Ubuntu
01:21 < chilicuil> la escencia del empaquetamiento es traer el software de upstream mientras se mantienen las
politicas de la distribucion, no traten de imponer sus condiciones sobre otros desarrolladores o usuarios
01:21 < chilicuil> usen las herramientas que sean apropiadas dependiendo el caso
01:22 < chilicuil> usen configuraciones por defecto que sean funcionales para la mayoria de las peronas
01:23 < chilicuil> un buen paquete, tendera a hacerse mas pequeño conforme sus cambios se incorporen en
upstream
01:23 < chilicuil> hay varias formas de mantener el codigo de un paquete
01:23 < chilicuil> en Ubuntu, todos los paquetes estan disponibles a traves de $ bzr
01:24 < chilicuil> por ejemplo: $ bzr branch ubuntu:paquete
01:24 < chilicuil> en debian, algunos equipos prefieren unicamente mantener en control de versiones el
directorio debian/, ya sea en git, svn o bzr
01:25 < chilicuil> verifica con el mantenedor del paquete para descubrir como lo hace
01:30 < chilicuil> dnewkirk pregunta la politica para nombrar paquetes, sabe que debera contener al menos
parcialmente la version del programa y tal vez informacion del directorio .git
01:31 < chilicuil> SpamapS responde que el nombre de los paquetes se componen de una version upstream y otra
de debian
01:33 < chilicuil> la version original debera mantenerse tan bien como sea posible, en el nombre de un
paquete lo que va despues de '-' es la version en Debian
01:33 < chilicuil> para debian, se limita a sumarse 1 por cada nuevo cambio
01:33 < chilicuil> para ubuntu, se le agrega 'ubuntu#' para anunciar que nuestra version contiene cambios
adicionales a los de debian
01:34 < chilicuil> asi que si tienes un paquete llamado foo con la version 1.2.3, en Debian sera 1.2.3-1
01:35 < chilicuil> si el paquete no esta en Debian, sino unicamente en Ubuntu se convertira en 1.2.3-0ubuntu1
01:35 < chilicuil> una nueva revision en debian puede contener muchisimos cambios, siempre y cuando se
especifiquen en debian/changelog
01:36 < chilicuil> ceno pregunto que significan las iniciales VCS y UDD
01:37 < chilicuil> el ponente responde que Version Control System o Sistema de control de versiones, y
Ubuntu Distributed Development, o Desarrollo Distribuido de Ubuntu
01:38 < chilicuil> TiMiDo ha preguntado si es necesario tener tu llave GPG firmada por algun desarrollador
(mientras se ven a la cara) para verificar nuestra identidad
01:39 < chilicuil> SpamapS responde que en el caso de Ubuntu no es necesario, ya que todo se hace a traves
de Lauchpad, en cuyo caso, Ubuntu cree en la identidad de tu cuenta
01:40 < chilicuil> para Debian, tendras que tener firmada tu llave por algun desarrollador de Debian, y la
mayoria insistira en un encuentro cara a cara
01:41 < chilicuil> aunque si solo haces empaquetamiento casualmente, sera suficiente que tengas un 'sponsor',
que patrocinara tus cambios, subiendolos en tu nombre
01:42 < chilicuil> TiMiDo ha preguntado si el hecho de ser un miembro de Ubuntu, esto es, si se le ha dado
un @ubuntu.com puede enviar sus cambios a launchpad y hacer cambios
01:44 < chilicuil> SpamapS responde que el hecho de que sea un miembro de Ubuntu, no le faculta para hacer
cambios a los paquetes, para tener acceso tendran que pedir permisos a la mesa de desarrolladores, Developer
Membership Board
01:44 < chilicuil> me gustaria compartir otro par de tips
01:45 < chilicuil> sbuild y mk-sbuild
01:45 < chilicuil> estas herramientas crean un chroot en su sistema que podran usar para crear paquetes
01:46 < chilicuil> mk-sbuild desde precise tendra una nueva opcion, --eatmydata que hara que sea aun mas
rapido de usar, desabilita la molesta funcion de llamar 'fsync' despues de cada operacion con archivos
01:48 < chilicuil> recomiendo que editen $purge_session="successful"  en el archivo /etc/sbuild/sbuild.conf
para que las compilaciones que fallen se mantengan en el sistema y se puedan reiniciar con 'schroot -c
sessionid'
01:48 < chilicuil> pueden listar las sesiones actuales con 'schroot --all-sessions -l'
01:49 < chilicuil> otro programa interesante es 'licensecheck2dep5'
01:49 < chilicuil> cuando se crea un nuevo paquete, necesitan asegurarse que la licencia del codigo fuente
este bien documentada
01:50 < chilicuil> puede correr $ licensecheck --copyright -r . 
01:50 < chilicuil> y el programa les dira las licencias que ha encontrado en el paquete
01:51 < chilicuil> para los paquetes que utilicen cdbs, existe un script licensecheck2dep5 que tomara la
salida de ese comando y lo convertira en un archivo debian/copyright por ti
01:52 < chilicuil> jincreator pregunto cual es la diferencia entre pbuilder y sbuild
01:52 < chilicuil> SpamapS contesta que aunque ambos tienen la misma premisa, crear un entorno para
compilar paquetes
01:53 < chilicuil> sbuild tiene algunas ventajas, la mas grande es que ese es el programa que las maquinas
de Ubuntu usan para crear los programas que despues estaran en los repositorios
01:54 < chilicuil> tambien esta el hecho de que sbuild puede usar las caracteristicas de snapshotting de
btrfs y de lvm para hacer el proceso mas rapido
01:56 < chilicuil> es todo lo que tengo por hoy, si quieren comenzar a empaquetar software, les recomiendo
entrar a #ubuntu-devel para trabajar juntos, gracias a todos por las excelentes preguntas!!!!
01:56 < chilicuil> con eso finaliza la charla de SpamapS
}}}