 Hola, bueno, pues bienvenidos, me da gusto que estén aquí y de lo que vamos a hablar es de cómo se empaquetan software para Debian y cuáles son las herramientas y procesos básicos para hacerlo. La razón por la que muchos de ustedes van a estar aquí es porque quieren participar en Debian, porque quieren integrarse a este proyecto, porque quieren viajar por todo el mundo, hacer nuevos amigos y de paso ayudar a la humanidad a convertirse en algo mejor, tener más avance y demás. La razón por la que hice esta presentación, por la que estamos manejando todo este track, es precisamente esa. ¿Perdón? No, ok. Puede ser a veces difícil saber por dónde empezar. A mi entender, siempre vamos a cruzar a través de este paso tarde o temprano, cómo se arma un paquete, qué es un paquete. Creo que esto es fundamental, no importa en cuál de las áreas del proyecto desean participar, lo que esperamos es que vean que hay diferentes áreas, pero creo que tarde o temprano todos pasamos por aquí. Entonces, los paquetes son… si se ve mejor así, sí. Ok, los paquetes son el principal mecanismo, la unidad básica de trabajo en Debian, el mecanismo de distribución de binarios. De lo que se trata de Debian es que hacerle fácil al usuario, al usuario final, tener un sistema coherente, completo, consistente, predecible. Y los paquetes nos dan precisamente eso. Un paquete, lo que yo hago es hacer una receta de cómo se va a compilar, cómo se va a preparar un conjunto de software para poderse distribuir de este modo al usuario. Y parte de este proceso implica no sólo cómo se prepara, sino que una vez que ya está hecho, qué requiere para ser utilizado, lo que llamamos las dependencias. Y bueno, dependencias incluye dependencias más suaves, dependencias más duras, ahorita vamos a hablar de eso. Y pues bueno, una suite o una distribución de Debian, una versión específica de Debian es un conjunto determinado de paquetes, de determinadas versiones que están ampliamente probados en su conjunto. O sea, han escuchado, por ejemplo, que Debian acaba de congelar Wi-Z. ¿Qué significa eso? Que la próxima versión que vamos a declarar estable en algún tiempo, probablemente cercano a los seis meses, ocho meses, pues bueno, ya no va a recibir nuevas versiones, ya no va a entrar nuevos software a Wi-Z. ¿Por qué? Porque tenemos que probar bien todas estas dependencias, que todo el software funcione bien con los programas pares, y asegurarnos que esto vaya de una forma escalonada, que se pueda actualizar de la versión anterior. Entonces nuevamente, si estamos pensando en los usuarios finales, pues hay que probar no sólo cada programa, sino que la integración entre ellos. Bueno, un poco esto lo platicaba ayer Videl en su plática. Un sistema de manejo de paquetes es una innovación de Debian, no existía ningún otro lugar antes que lo incluyera a Debian, alrededor del 98. Primero, como de Select, pero en general nos referimos a esto como Upt, como una herramienta de paquetes, Apacash Tool, que es el programa encargado de manejar, que si yo quiero instalar un programa, bueno, depende de este, este y este, entonces los traigo todos en un conjunto. Y entre las principales funciones de Upt está resolver dependencias y conflictos. Un conflicto es un tipo raro de dependencia, un programa puede requerir a otro, se puede depender de otro, pero puede que haya dos programas que no trabajan bien cuando ambos están instalados, entonces también puedo tener que declarar un conflicto entre ellos dos. Y pues esta infraestructura tiene que saber evitar los conflictos. Obtención de paquetes, parte de lo que hace Upt es, bueno, me pidieron un paquete de dónde voy a traer cada uno de los componentes, pues de este depósito de software, de este CD que tengo, de este lugar que ya lo baje al caché. Y una vez que tengo todos los paquetes en mi disco local, va a ir llamando a DPKG, al herramienta específica para instalar cada paquete independiente en el orden correcto para hacer de esto de forma coherente, consistente. Ahora, qué me da el manejar paquetes, por qué no, por ejemplo, como sigue haciendo Slackware, como hicieron muchas distribuciones, mucho tiempo, por qué no nada más manejar, digamos, tarballs, o sea, descomprimir pedazos de software en el lugar correcto que luego puedo borrar manualmente. Bueno, porque con los paquetes puedo agregar software nuevo, puedo encontrar, o sea, bueno, hay mucha más información, no solo el software mismo, hay mucha información relacionado con cada uno de los paquetes, por ejemplo, puedo encontrar cuáles son los paquetes huérfanos, recordarán de ayer de la plática de Mónica, que era de cómo ayudar al equipo de control de calidad, pues ellos se basan mucho también en esto. Los paquetes son también básicos para corregir bugs, o sea, yo no reporto que hay una falla en determinado archivo, sino que la falla la reporto sobre un paquete y pues ya el mantenedor de todo ese paquete como una unidad, como una unidad de infraestructura, sí, va a encargarse de ver, bueno, en realidad a qué pertenece, a qué corresponde. Bueno, van a ver la siguiente plática ahora que suba Christian para traducir las cadenas de un programa, lo hacemos paquete por paquete. Vamos, es una manera de segmentar la realidad para trabajar con un aspecto específico, con un grupo de archivos relacionados entre sí. Bueno, les dije que estos son recetas de compilación y cosas ya compiladas. ¿A qué voy con esto? Bueno, el usuario final, el usuario que no sabe de cómputo y quiere tener una solución, lo que quiere son los paquetes binarios, es lo que corre directamente en la computadora. Sin embargo, para trabajar con ellos, vamos a trabajar siempre con los paquetes fuente. Y bueno, lo que define y lo que voy a abordar aquí principalmente, qué son los paquetes fuente, pues es el proceso de compilación y de construcción. Normalmente vamos a ver tres archivos, o sea, si bien un paquete binario lo han visto es un archivo nombre, guionbajo, versión, guionbajoarchitectura.dev, pues bueno, el paquete fuente son tres archivos. Normalmente pueden ser dos o pueden ser más, pero vamos al caso general, son tres. Un archivo.orig.tar.gz, que es el archivo original que recibí del autor. Un archivo.debian.tar.gz, que son las adecuaciones que yo le estoy haciendo. Y un archivo de descripción, punto DSC, que describe el paquete fuente para que la infraestructura sepa cómo manejarlo. También, vamos a ver un momento, puedo declarar dependencias de construcción. O sea, el paquete sabe qué es lo que necesita estar instalado antes de trabajar con él. Y pues bueno, cuando construye el paquete se generan todos estos archivos. Bueno, ¿cómo se vende desde fuera? Sí, bueno, esto es precisamente lo que acabo de describir, ¿no? Orístar.gz.debian.tar.gz. y DSC. Ah, y muy importante, el DSC lleva la firma de la persona responsable por subir ese paquete. Usamos un esquema criptográfico, esto lo va a enseñar mañana Daniel, cuando hable de GPG. Un punto fundamental de por qué podemos confiar en Debian es porque todo lo que subimos que va a ser el usuario va firmado por una persona. Y esa persona se compromete, se hace responsable de la calidad del trabajo que está haciendo. Bueno, dentro del paquete, ¿qué pasa si yo tomo, creo que estaba aquí, si yo tomo mi paquete fuente que tiene estos tres archivos y le pongo DPKG source-x como lo muestro aquí. Por ejemplo, DPKG source-x y el nombre de un programa descomprime ese paquete fuente y me voy a encontrar con un directorio llamado Debian. Dentro del directorio de Debian va a haber un tiradero de archivos. Los principales los que siempre vamos a ver ahí son cuatro. Control, Rules, Copyright y Chainslog. Va a haber muchos más, vamos a ver brevemente la función de cada uno. En Control está la información básica del paquete fuente. O sea, toda esta declaración de dependencias, versiones mínimas máximas de las dependencias que tiene, una descripción de cada uno de los paquetes generadas, todo eso va en el control. Y ahorita vemos un ejemplo de esto. Rules es la receta de cocina. Rules es un archivo escrito con la sintaxis del Makefile. Es bastante sencillo, en realidad, especialmente gracias a la tarea del asistente, de DevHelper, que aquí pueden también platicar con mucha gente, incluido quien lo hizo, quien lo maquetó, que verdaderamente nos simplificó la vida. Copyright tiene la información detallada de derechos de autor de cada uno de los archivos que contiene nuestro paquete. Esto es muy importante. Si yo bajo, por ejemplo, me he encontrado con aplicaciones web, son de las peores ofensoras, pero casi cualquier cosa que yo baje de internet no estoy bajando solo los archivos fuentes de un autor, es típico que para facilitarse la vida incluyen copias de dependencias de otros programas. Entonces en Copyright tengo que documentar cada uno de los archivos que tengo ahí, qué licencia tiene, cuál es el autor, cuál es la información de contacto. También siguiendo un formato que ahorita vemos. Y el ChangeLog es la Vittacora, o sea la lista de cambios que ha venido registrando este programa. ¿Por qué? Pues para permitirle a una persona ver cómo ha ido evolucionando, ver cómo es la respuesta del desarrollador a los problemas que hay, tanto para ver qué tan estable es el programa que está bajando, como para ver qué tantas fallas ha habido registradas, cómo se han ido resolviendo. Y pues bueno, viéndolo ya desde el punto de vista del desarrollador, si yo quiero saber a quién contactar, quién puede saber acerca de ciertas decisiones de desarrollo, pues ahí está. Ok, pues aquí está más o menos cómo lo usaría. Si yo quiero trabajar con un paquete llamado un paquete, entonces le digo AppGetSource un paquete. Eso me trae el paquete fuente para acá y lo descomprime. Esto es, voy a terminar con estos cuatro archivos en mi directorio. Este primero es un directorio, el directorio un paquete y estos pues son los tres componentes del paquete fuente. Ahora, si quiero construirlo y convertirlo en un paquete binario, entro al directorio y llamo a este ayudante mágico que es DPCA Heavy Package. Hay muchos otros que hacen esta tarea y algunas más. Especialmente se que van a ver, por ejemplo, cómo asistirse para la construcción con sistemas de control de versiones, como Git, como subversion. Estos provenen en voltura sobre este mismo programa. Pero bueno, el caso básico es este y el resultado esperado va a ser tener un paquete binario, un paquete 2.1.1.1.1 bajo 386.dev o algo equivalente. Bueno, los cuatro archivos mágicos que les mencionaba dentro de Debian, tengo Debian Control. En Debian vamos a ver muchos archivos con lo que llamamos el formato de RFC 822. Cuando ustedes ven los encabezados de un correo, es en este mismo formato en que tenemos la descripción del campo, dos puntos y el contenido. Entonces Debian Control es una serie de párrafos RFC 822, cada párrafo describe, ya sea el primero describe al paquete fuente y todos los siguientes van a describir a los paquetes binarios que se van a generar. De aquí pueden olvidarse casi de todo por ahora, los campos son bastante auto descriptivos. Lo que importa es el nombre, surge un paquete, el mantenedor soy yo, es la persona que está haciendo este trabajo, aunque pueda haber otros varios en uploaders. De qué otras cosas depende y la versión de estándares nos indica qué tan nuevo que tan viejo es este empaquetamiento. Después vienen las siguientes secciones, los paquetes binarios que voy a generar. En este caso por ejemplo tenemos un paquete que recomienda que instale a un paquete data y depende de otro paquete y pues tiene una descripción de para qué tenemos esto. Ahora ¿por qué puede estar yo separando un paquete en dos? Imagínense que es un programa, una biblioteca que se compila un archivo binario, pero depende de una base de datos que trae, que incluye. Pues esta base de datos es un conjunto bastante grande que no quiero estar repitiendo, que no quiero incluir 11 veces en el archivo. Entonces lo que hago es separarlo en dos. Por eso estoy creando aquí un paquete y un paquete data. En fin aquí hay varios detalles que si quieren luego ver en la presentación, que ya tengo subida aquí al siempre famoso penta, si quieren ver esta presentación pueden bajarla o luego entramos en detalles. En realidad como nunca he dado esta plática no sé cuánto tiempo me va a llevar y no quiero pasarme el tiempo permitido. Bueno en copyright vamos a encontrarnos que paquetes ya existentes en copyright nada más, o sea es un archivo de texto, un archivo de texto seguido en que se dice bueno y este sigue tal licencia y este es el texto de la licencia y estos son los autores, pero desde hace un par de años ha habido un empuje para convertirlo en algo estandarizado en un formato seguible por computadora para poder hacer números más generales, para poder hacer un buen seguimiento. Entonces van a encontrarse, puede encontrar la descripción de este formato en esta dirección. Es un formato muy fácil de llenar, un poco laborioso, pero nos permite hacer un seguimiento completo de si verdaderamente estamos cumpliendo con este análisis bien. Bueno esto ya se los mencioné, la autoridad de los archivos internos. A veces pasa que yo tengo que reempaquetar algo, bueno en alguna de las minas anteriores mencionaba algo de las fuentes prístinas, o sea cuando yo proceso el código fuente está el principio de no modificar lo que baje del autor, porque así el usuario puede verificar que yo no esté meneándolo, que no esté cambiando lo que el autor me dio, porque bueno puede que el usuario no me conoce a mí, no tiene porque confiar en mis intenciones. Cuando yo tengo que hacer alguna modificación por ejemplo por asuntos legales porque incluye algún componente no libre, lo normal es que yo reempaquete el programa agregándole el número de versión más DFSG, o sea por el linamiento de software libre de Debian. Por ejemplo la versión 0.1.2 se volvería 0.1.2 más DFSG y pues explicaría cuáles son las diferencias. Así se ve hoy en día un archivo de copyright standard, pueden ver que tiene solo un par de campos, indica cuál es el formato que está siguiendo, cómo se llama el archivo en el depósito del autor, cuál es la fuente del que lo baje y a todos los archivos se aplica esta licencia y el titular de derechos está el persona. Muchas veces son bastante más elaborados que esto, por ejemplo casi siempre el autor del programa es diferente del autor del empaquetamiento, entonces seguramente tendré un tercer párrafo diciendo bueno los archivos que están dentro del directorio de Debian fueron de otra persona, bueno Debian Change Rock es otro archivo muy importante, sin esto no se compila, de aquí se toma cuál es el número de versión que vamos a usar y hay varias indicaciones que se pueden hacer a través de esto para el sistema de seguimiento de fallas, para el bug tracking system, por ejemplo si bien yo podría nada más arreglar el paquete, corregir cualquier cambio y subirlo y punto, lo normal es que si yo hago una modificación que arregla un bug, lo marco acá, de ese modo cuando el archivo de Debian recibe mi paquete le notifica el sistema de seguimiento de fallas, casi siempre con buenas excepciones pero casi siempre van a ver que en cada bloque que subo algo va a haber algún bug que se está cerrando o sencillamente que es una actualización menor, bueno Debian Rules, hoy en día se ha vuelto un archivo mágico, o sea estas tres líneas es el archivo de Debian Rules más común que se van a encontrar y esto significa no me importa cómo tú hazlo, Debian Helper es una maravilla que escribió el autor líder, hoy en día esto es Joby Hess, que es una serie de programas que adivinan qué es lo que estoy intentando empaquetar y hacen el empaquetamiento, obviamente tienen todos los, le llamamos los ganchos, los hooks necesarios para que si yo tengo que meter la mano para cambiar parte del estilo de este empaquetamiento lo pueda hacer, pero bueno, este archivo hemos mantenido la convención de que está siempre escrito en GNU Make, una sintaxis un poquito esotérica que hay que aprender pero bueno no es mayor complicación en realidad y bueno cada uno de estas cosas que están antes de un símbolo de dos puntos se llama un objetivo, los objetivos básicos son Build, Clean, Binary y puede haber subos objetivos como Binary Arc, Binary in depth, etcétera. Nuevamente pues la documentación son los manuales, esto hoy en día nos lleva a la mayor parte de los casos, esto es una manera de cómo cambiar parte del comportamiento de este archivo, si yo después del archivo de otras líneas que les mencioné, incluyo esto, esto, un override como lo puse aquí es una desviación, yo le puedo decir bueno cuando estás haciendo el paso de H install, o sea cuando estás llamando a la parte del asistente que se llama install, entonces en vez de hacer eso haz lo que te digo aquí y en primer lugar digo pues tú instala antes que otra cosa, como dirían en México mata los luego averiguas, tu instala, pero ya que instalaste mueve un archivo de un lugar a otro, en este caso por ejemplo estoy moviendo dentro del directorio de archivos estáticos de barlib, estoy moviendo los datos a un paquete data, si se acuerdan habíamos quedado que iba a ser un paquete aparte para manejar la parte de datos grandes, ok y pues bueno puede haber muchos archivos adicionales, los más comunes que vamos a ver nuevamente siguiendo el estándar de H de the helper son Deers, install, man pages, docs, o sea es como creando estos archivos yo básicamente le estoy dando a DH como si fueran argumentos en la línea de comando, en install por ejemplo le digo te vas a encontrar un archivo acá ponlo acá, un archivo acá ponlo acá, un patrón de archivos acá ponlo acá, como si estuviera copiando cada uno, en Deers pues cada directorio que yo le liste lo va a crear dentro del paquete objetivo y también están los scripts de mantenedor que dentro de esto se está acercando ya más a la parte esotérica, no me quiero meter con cosas esotéricas, las vemos si quieren cualquier día de la semana pues acércense a cualquiera de nosotros y platicamos acerca de cómo operan los scripts de mantenedor pero bueno los clásicos son cuatro, antes de instalar, después de instalar, antes de borrar y después de borrar. ¿Qué acciones hago ahí normalmente? Por ejemplo si yo estoy instalando un servidor web pues casi siempre voy a crear un usuario para que el servidor web corra bajo su nombre, entonces en la pre instalación creo es usuario y probablemente en la post remoción loquito, hay ciertas reglas para ver qué va en la pre y qué va en la post porque hay cosas que puedo hacer antes de instalar pero normalmente intento hacerlas después de instalar. Bueno, en resumen ¿qué hace falta saber para hacer un paquete de devian? Aparte obviamente de entender lo que estoy empaquetando porque es muy importante que yo entienda los paquetes que voy a generar, bueno primero que nada programación en shell, todo lo que voy a hacer es básicamente lo que estaría haciendo un administrador de sistemas que quisiera instalar ese paquete en su máquina y pues bueno tener una manera unificada de luego poderlo quitar, entonces lo primero que tengo que saber es programación en shell, sintaxis básica de make, básica, digamos hay otros asistentes de empaquetamiento que les sugiero evitar pero que tarde o temprano si se involucran los van a terminar usando, por ejemplo uno de los que fue bastante popular es CDBS, el sistema común de construcción de devian cada vez se usa menos pero todavía nos lo encontramos de rato en rato y está basado en magia avanzada de make, es una cosa rara pero bueno, en general necesitamos la sintaxis básica, bueno estructural información en un archivo de texto plano, vieron qué varios de los archivos que les mostré son RFC 822 no hay complicación con eso y familiarizarte con la familia de comandos de DH, si yo pido el manual de DH me va a referir a cinco manuales para las cinco fases principales de construcción, build, clean, install, y cada uno de esos dentro pues me va a referir a otras 10, la cosa es como les dije hoy en día construir un paquete puede verse como un acto de magia pero es un acto de magia que nos permite ser muy introspectivos, no hay magia oculta, no hay magia negra, podemos ver cada uno de los pasos y normalmente o sea cuando yo tengo un problema de construcción de algún paquete pues lo que hago es ver, ok, sigo la vitácora hasta donde llegó donde se atoró, ok, la página manual del comando inmediato anterior, no tengo todo digamos fresco en memoria, antes me acuerdo cuando, bueno, no estoy seguro si se sigue haciendo, parte del cuestionario que se aplicaba cuando estábamos procesando una nueva persona que quería entrar a ser desarrollador, era ok, hace un paquete sin usar ninguno de los asistentes, no es muy difícil, o sea hacer un paquete simple es bastante sencillo pero estas cosas verdaderamente nos han cambiado la vida, platicábamos el otro día por ejemplo con el grupo de empaquetamiento de Perl, yo trabajé con ellos bastante tiempo, el tiempo total que les toma hacer un paquete y claro Perl es un lenguaje muy estable, muy regular, entonces las prácticas son casi las mismas siempre pero les toma como 20 minutos desde que dicen ah quiero empaquetar esto hasta que lo están subiendo a Debian y pues bueno vamos, eso es perfectamente posible, bueno nuevamente como les dije cuando empecé con esto hay muchas maneras de participar en Debian y eso es algo que les van a repetir hasta el cansancio, pero pues para colaborar en serio tarde o temprano vamos a terminar empaquetando algo, corrigiendo un paquete, metiendo las manos, aunque sea para corregir un bug o para hacer alguna traducción o para uso local por ejemplo la mayor parte de los paquetes que yo hago hoy en día solo existen en el servidor de mi instituto y bueno no sé si tengan usuarios aparte de mí mismo, lo dudo, no creo que nadie le interese, pero pues bueno el sistema empaquetamiento de Debian es tan cómodo, el sistema que le entregamos a los usuarios es tan cómodo que yo también quiero tener esas ventajas incluso si es con software que no me atrevo a subir a Debian sea por lo que sea. Ahora dices pues no, todo esto suena muy técnico a mí no me interesa, bueno pues no te preocupes sigue habiendo muchas otras áreas para participar y bueno el puro hecho de que estén aquí ustedes en Managua el día de hoy o la gente que nos está siguiendo por el stream o alguien que baje esta presentación a futuro que espero que las haya, este pues bueno el puro hecho de mostrar ese interés significa que hay áreas en las que pueden participar. Aquí hay algunas referencias útiles creo que es importante tenerlas a la mano especialmente cuando estamos empezando a comprender cómo se maneja este mundito, la guía del nuevo mantenedor la han ido actualizando, yo aprendí con esa guía y pues bueno ha ido cambiando mucho con los años pero bueno nos dice cómo llegar de tener un programa recién bajado de un lugar aleatorio en internet a tener un paquete binario generado con algunas pequeñas complicaciones que podemos encontrarnos. La referencia del desarrollador de Vian es una guía mucho más profunda que se mete en varios de los detalles de empaquetamiento entonces esa vale la pena mantenerla como un libro de referencia. Está el tutorial la guía de creación de paquetes de Vian esa siendo nuestros recién la vi por primera vez mientras estaba preparando esto se ve bastante bien es una presentación o sea el estilo de esto de láminas hay algunas personas que prefieren seguir las láminas así que pues queda ahí disponible y por último las políticas de Vian el documento políticas de Vian es técnico y largo y podría verse tortuoso para algunos pero verdaderamente a mí se me hace bello o sea es una de las cosas que antes de entrar a trabajar en Vian estuve leyéndolo un poco y pues bueno es probablemente eso lo que me hizo elegir este proyecto sí es lo que asegura más que la estabilidad la congruencia si es un documento que dice esto debe ir aquí por tal razón esto debe ser hecho de tal manera entonces si yo sigo esas políticas los todo lo que yo escriba va a incluirse bien en un sistema de Vian y pues va a tener sentido cuando cuando yo lo quiere integrar y pues bueno hasta ahí llega mi presentación entonces si tienen alguna duda por hacer con mucho gusto les respondo sí mr. talk maester please tenía una consulta y es en el estado actual en el que me encuentro ya tengo un paquete ya pasó el dolor de cabeza que se llama que hace el test que uno lo pone inclusive en te cerca por un poquito por favor que en este momento me encuentro digamos desarrollando un software y ya estoy en una etapa en donde tenemos el paquete que pasó a este este chequeo de los paquetes este software que chequea los paquetes como se llama en modo paranoico y ahora que ok ahí tengo el archivo y ahora que como algo que llega de bien ok la pregunta es básicamente ya hice mi paquete se ve perfecto en mi computadora quiero subirlo a Vian ahora que hago bueno en primer lugar existe el depósito de mentors o sea bueno partiendo de que si no eres desarrollador actualmente no tienes privilegios para subirlo lo que haces es honestamente yo no uso mentors que hay aquí hay gente que se los va a recomendar con más conocimiento que yo pero entra a mentors punto de vian punto net ahí puedes subir el paquete y pedirle a un desarrollador que lo baje y lo revise ahora antes de subirlo a mentors vamos antes de haber empezado en paquetarlo debiste haber hecho una cosa no nos gusta trabajar doble no nos gusta hacer trabajo de más estás de acuerdo lo primero que tienes que hacer antes de empezar a hacer un paquete es revisar entre los bugs del paquete del paquete virtual w n pp work needed and prospecting packaging o sea trabajo necesitado y paquetes en prospecto lo primero que haces ahí es decir a ver alguien empezó a empaquetarlo ya o empezó a empaquetar algo parecido si si bueno pues le escribes a esa persona para que unan esfuerzos si no entonces registras un bug o sea mandas a través de report bug creas la solicitud de crear un nuevo paquete cuando cuando cuando mandas ese bug va a ser mandado de una copia en automático a la lista de desarrolladores de vian de modo que otras personas te pueden decir no no no ni te metes con ese paquete porque tiene problemas que tiene documentación no libre bla bla bla lo que sea o pueden decir así buena idea o puede que no te diga nada que es lo que es lo más común o sea hay veces que mandas ahí tus reportes y suena que estás hablando ante el abismo bueno ya mandaste tu bug creas tu paquete limpian o sea limpian para que te apruebe un paquete para que te diga ok estoy de acuerdo con esto si es un paquete nuevo entonces la primer línea del changelog debe ser estoy cerrando este bug porque pues porque está cerrando el bug de que falta ese paquete bueno lo subiste a mentors o contactaste por por algún otro camino con un desarrollador digamos si tú me conoces a mí sabes que estamos trabajando más o menos en lo mismo puedes decirme a ver hoy échale un ojo a este paquete a ver qué te parece contactas con un desarrollador por el modo que sea y bueno el siguiente paso es que un desarrollador lo suba punto o sea en el momento que tú ya lo mandaste a mentors y le pediste a alguien o le pediste a alguien en corto pues se crea el paquete y lo sube no aparece de inmediato cuando se sube software nuevo a devian tiene que ser aprobado por el equipo de ftp master o sea por los responsables del depósito completo se hacen básicamente dos chequeos uno es imagínate limpian pero con cerebro humano o sea ven el paquete sin correrlo ven que ven que tiene sentido es en ok y por otro lado revisan que lo que tú hiciste en devian copyright o sea que la que que la información de derechos de autor es consistente con con lo que dice el programa si si entonces lo suben puede tomar no sé un par depende de cómo estén en ese momento entre un par de horas y un par de semanas y ya y bueno a partir de ese momento tú eres el responsable así que tienes que mantenerlo al día a ver micro si es que cómo están grabando si en este caso es un paquete nuevo ok y yo soy upstream entonces realmente yo no quiero mantener el paquete pero bueno no me queda de otra porque no he encontrado ningún colaborador para reportar el bug y todo eso tengo que ya ser yo que me involucre directamente con devian o sea yo no puedo llegar a mentor si decirle alguien si quiere hacer cargo de este paquete mira si tú eres upstream es mejor todavía porque pues bueno cuando te reporten un fallo tú como mantenedor no se lo vas a tener que reportar a nadie más el paquete el proceso es el mismo o sea tú vas a llegar a mentors y en cuando una persona sube tu paquete en mentors digamos si yo subo un paquete tuyo igual yo me hago responsable pero sólo hasta cierto punto yo no conozco el software pero tengo que ver revisado que se vea decente pero el responsable eres tú ahora por ejemplo si tú a mí me pediste que suba una versión y ok yo la subo luego yo me voy de vacaciones tú me pides que subo una versión estoy de vacaciones hay un depconf ok este me vuelves a mandar un correo no después me fui a pasear por nicaragua sabes que te hartas le escribes a otra persona la otra persona lo sube yo no tengo por qué nojarme yo no soy responsable de tu paquete yo te ayudé a subirlo el responsable eres tú entonces tú como upstream estás en la mejor de las posibilidades o sea conoces el programa mejor que nadie sabes cómo se debe construir sabes bien de qué depende sabes qué es lo que le ha incluido y qué es lo que no entonces la información legal la tienes completa punto sube o sea nada más partes del mismo archivo que le estás distribuyendo a tus usuarios ese archivo lo conviertes en tu paquete fuente le agregas el directorio de vían y punto hay algún otro aquí al frente por favor bueno y tengo una pregunta más relacionada con lo que son un paquete de tu uso personal por lo menos yo necesito a veces mi trabajo hacer deployments entonces qué tan viables hacer paquetes para hacer deployments de configuraciones que yo tengo mira de problemas de configuraciones es una cosa particular los paquetes parte de la política de vían es que los paquetes no tocan la configuración de hecho en el momento en que yo pongo un archivo en etc ese archivo es marcado para adecuación local entonces por ejemplo si el administrador local lo modifica y llega a una nueva versión del paquete el nuevo archivo no se vaya a instalar encima en todo caso hay algunas herramientas por ejemplo ucf que me ayudan a integrar las modificaciones locales para hacerle más fácil la vida al administrador pero bueno digamos de ploviment de configuración no es el ámbito del empaquetamiento para eso te sugería por ejemplo usar herramientas como puppet como chef ahora yo lo yo lo uso para deployment de no le puedo decir binarios no es de script porque digamos para algunas aplicaciones web que tengo y tengo mi depósito personal mi depósito apt en mi oficina y ahí subo mis mis paquetes lo bajo de mis otros servidores virtuales lo que sea pero para archivos de configuración precisamente no no no no es la herramienta adecuada a alguna otra mano por favor si bueno si si bueno este nada más está probablemente es una pregunta trivial pero si nosotros hacemos un archivo de de fuentes con con pirex por ejemplo entonces qué tan fácil es hacer que el archivo de binarios se genere automáticamente o sea tú puedes escoger trivialmente el el compilador que vas a usar si mira bueno no recuerdo exacto el caso digo yo ya trabajé con él haciendo un paquete con fuentes en pirex no recuerdo exactamente cómo operaba pirex pero te puedo decir de de varios grupos por ejemplo como operábamos en el grupo de ruby hasta hace año y medio era que a cada paquete fuente se le generaban uno o dos o tres paquetes binarios uno para ruby 18 uno para ruby 19 y a veces uno de datos y lo teníamos que declarar formalmente cada uno de ellos ahora eso así era también antes hace cinco seis años creo el proceso compiton cuando estaba dos dos y dos tres eso es muy costoso en tiempo de mantenedor y es como se llama es bloat es este infla el archivo o sea el depósito de paquetes porque se crean muchos paquetes binarios casi idénticos entre sí entonces bueno primero el equipo de python y bueno después del equipo de ruby hicimos algo similar digamos se reempa se rehizo la infraestructura en paquetamiento de ese lenguaje para que en la medida de lo posible subas un solo paquete binario que funcione con ambos intérpretes que son versiones bastante distintas entonces nuevamente en el equipo de ruby lo que hacemos es poner ciertas banderas en el archivo de vían control que es donde declaras las dependencias que dicen bueno es posible compilar con las versiones todas ruby 18 ruby 19 probablemente luego ahí agregamos por ejemplo el ruby de javas y se puede incluir el ruby de net o sea para los diferentes intérpretes que puedan entenderlo y ahora sí o sea el archivo que el archivo que ya está dentro sí se puede presentar a algunas situaciones medio raras por ejemplo si un usuario tiene instalada en su máquina ambas versiones ambos niveles del intérprete lo que estamos tendiendo ahora es que por ejemplo para weezy ruby va a estar por default en 191 pero si tú solo si tú eliges instalar 18 y borrar 191 bueno se van a borrar algunos paquetes pero si decides tener ambos pero tener por default el 18 y algunas cosas funcionan con uno y no con el otro vamos estamos probando esas cosas precisamente creo que otra vez de hecho esa parte también me interesa pero una pregunta ligeramente distinta porque yo estaba hablando no de python sino de pyrex que si compilador pero y lo que tu pregunta me me recordó es que nosotros en el archivo de configuración hay dos compiladores para pyrex seitan y pyrex y nosotros en el archivo de configuración tenemos para que le pongas este con cuál de los dos quieres compilar lo que tenemos ahí es este si tú quieres usar seitan como compilador o si tú quieres usar pyrex como compilador porque pyrex está un poquito atrás en versiones y el no es muy amigable pero pero bueno es un detalle específico yo sugeriría que detalles específicos los vemos digamos en otro entorno porque bueno aquí lo mantenemos como algo más general yo no te voy a poder responder eso porque no lo conozco te planteo la duda para que claro que no la responda sólo dejamos ahí yo yo sugeriría marear menos yo conozco el problema con con pyrex y seitan y en realidad no lo conozco entonces incluso si la planteas probablemente yo no te puede dar mucho la respuesta pero pero creo que vamos si la idea de esta plática es una presentación general marear a la gente es mala idea pero bueno yo creo que una última y este pido disculpa por lo básico de la pregunta verdad al contrario en qué lenguaje se puede programar para débil pues mira como decía hace rato como les decía hace rato el lenguaje en el que se pueda programar prácticamente el que quieras prácticamente cualquier lenguaje que tenga una implementación libre está empaquetado ahora qué tienes que saber si estás empaquetando en debían es esto o sea shell make y texto plano pero qué lenguaje puedes usar para programar algo que vayas a subir a debían cualquiera bueno pues yo creo que ahí cerramos por ahora y nuevamente las láminas van a están ya disponibles en penta y pues este las tendré pronto también en mi sitio en jeowolf.org y pues muchas gracias