Ubuntu Wiki

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