Re: Sintaxis del fichero rules
On Thu, 21 Aug 2008, Pedro Castillo López wrote: Hola de nuevo, esta vez tengo unos problemillas a la hora de personalizar un fichero rules y escribir en él. Resulta que la sintaxis del fichero rules es realmente la de un Makefile y no estoy familiarizado para nada con ella, mira que he mirado veces el manual oficial ( http://www.gnu.org/software/make/manual/make.html), pero no doy pie con bola... Las tareas que quiero que desempeñe el fichero rules las tengo escritas en un script y funcionan perfectamente, lo que pasa es que el paso del script al fichero rules no es inmediato. Os pongo unas líneas de código del script para ver si podéis echarme un cable: RETORNO=$(aptitude search paquete | grep '^i' | wc -l) if [$RETORNO -eq 1 ]; then echo Paquete instalado else echo Paquete no instaldo fi De esta forma, dentro del fichero rules he hecho la siguiente prueba: RETORNO=$(shell sudo aptitude search paquete | grep '^i' | wc -l) @echo $(RETORNO) Obteniendo el siguiente resultado por consola en el proceso de compilación del paquete: ... RETORNO=0 ... La línea en blanco de la salida corresponde a la 2ª instrucción. Me gustaría que alguien pudiera traducirme de forma correcta el anterior trozo de código del script y que me explicara los resultados obtenidos en la prueba que hice. La traducción de lo que quieres hacer es usar un Build-Depends en el fichero debian/control, no hay que hacer nada en debian/rules. Si estás leyendo el packaging manual, sigue leyendo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Consejos para paquetes nuevos de TCOS
On Sat, 17 Feb 2007, mariodebian wrote: Las Xorg de Debian (y sobre las de ubuntu) dependen de discover1 (que está programado en perl), como no estoy dispuesto a meter Perl en los terminales prefiero usar discover2 (o discover a secas) que es un binario compilado estáticamente y varios shell scripts. Para evitar que los usuarios de TCOS rompan esa dependencia (desintalar discover1 a favor de dicover) he creado el paquete tcos-discover2 que lo que hace es en el momento de la compilación (dpkg-buildpackage) se descarga con wget los deb de discover2, los descomprime y los mete en $DESTDIR/usr/lib/tcos/discover [3] Reconozco que es una chapuza bastante curiosa pero no conozco otro método para hacer esto con el menor impacto sobre la distro padre posible. No entiendo nada de nada. Si un paquete necesita cosas de otro paquete, lo que se hace es usar un Depends, no copiar su contenido. ¿Por qué cambiar las cosas de sitio? ¿No puedes hacer para que se usen las cosas de discover2 allá donde estén y usar un simple Depends, que para eso se inventó? [...] * Seguir como hasta ahora (no se qué dice la debian policy sobre este caso), es decir, en tiempo de compilación descargar deb y descomprimirlos en $DESTDIR/usr/lib/tcos No hace falta que mires la debian policy, cualquier ftpmaster te quemaría por hereje si haces eso. Piensa en cualquier otra cosa.
Re: Paquetes nativos o no: duda
On Fri, 27 May 2005, Victor Moral wrote: Ahora bien, resulta que el software que escribo está hecho sobre y para Debian, aunque no tenga que ver con el proyecto en sí, por lo que no tengo un lugar de dónde bajarlo (incluso en los repositorios cvs aparecen los directorios y archivos ./debian), así que al final no estoy seguro de si debo hacer que los paquetes sean nativos o es algo reservado a los desarrolladores oficiales. Lo que debes hacer es lo que te resulte más cómodo. Si lo que hay dentro del paquete lo has hecho tú, y no hay ningún archivo .orig.tar.gz ajeno que tengas que respetar, entonces no hay necesidad de complicarse la vida haciendo el paquete no nativo. No hay nada reservado a los desarrolladores oficiales. Las herramientas de empaquetamiento son software libre, así que puedes usarlas de la manera que prefieras tú.
Re: Paquetes nativos o no: duda
On Fri, 27 May 2005, Miriam Ruiz wrote: la explicación de es que me es más fácil así no me convence. Creo que es mejor hacer las cosas bien. La mayoría de los empaquetadores más experimentados que conozco suelen recomendar crear paquetes no nativos siempre por defecto, salvo que sea algo específico de Debian. ¿Y cuál es la explicación que te convence a tí? ¿El argumento de autoridad? Nueve de cada diez empaquetadores lo recomiendan. Preferiría hablar del tema con argumentos técnicos, no porque fulanito diga esto o lo otro. El motivo principal de que los .orig.tar.gz existan es que se considera deseable tener claro qué parte del código fuente proviene del autor y qué parte la hemos añadido nosotros después. Como motivo secundario, cuando el paquete fuente sufre cambios frecuentes debidos a empaquetamiento y cambios poco frecuentes en el código real, entonces un .orig.tar.gz puede ayudarnos a ahorrar ancho de banda. Así que si el paquete es nuestro en su totalidad (tanto el código como el empaquetamiento) y no tenemos problemas con el ancho de banda, entonces no hay razones *de peso* para preferir un paquete no nativo sobre uno nativo. Ojo, que no estoy diciendo que un paquete nativo sea mejor, sólo digo que si en un caso concreto en el que no hay código fuente original por ser todo nuestro no somos capaces de apreciar la diferencia entonces puede que no sea tan importante. Con esto pasa como con la pregunta típica del usuario novato: ¿cómo debo hacer las particiones?. No hay debes para eso. Si tiene uno que preguntarlo es que no importará tanto, y a lo mejor es preferible dejar que sea la experiencia la que nos enseñe qué es realmente lo mejor para nosotros, que no tiene por qué ser lo mejor para el resto del mundo. Es un tema que suele suscitar bastantes controversias en muchas listas. Concretamente sale a menudo en la de debian-mentors, así que seguramente podreis localizar conversaciones con información interesante al respecto en los archivos de esta y otras listas. Como ejemplo pongo esta referencia: http://www.webservertalk.com/archive97-2004-4-178851.html Efectivamente, no respetar un .orig.tar.gz que YA exista es una auténtica cagada, pero no es de eso de lo que estamos hablando. No hay nada reservado a los desarrolladores oficiales. Las herramientas de empaquetamiento son software libre, así que puedes usarlas de la manera que prefieras tú. Evidentemente sí. Tu sistema es tuyo y puedes usarlo de la manera que prefieras, pero eso no quita que haya formas de hacer las cosas más aconsejables que otras. Los paquetes nativos no están reservados a los desarrolladores oficiales, sino a los paquetes específicos de Debian, los desarrolle quien los desarrolle. Pues no sé qué entiendes por específico de Debian, pero te pondré un ejemplo: El paquete rbldnsd, que yo me encargo de poner en unstable cuando el autor me lo pide, es nativo. El autor y yo sabemos perfectamente que cualquier cambio de empaquetamiento requeriría hacer un .orig.tar.gz, pero hasta ahora no ha sido necesario, así que dado que él prefiere mantener el paquete como nativo y a mí no me importa, pues nativo se queda. Todo lo que hay en el paquete lo ha hecho él, pero el paquete no es específico de Debian.
Re: Paquete sysvinit, Conflicts: last
On Thu, 16 Dec 2004, Ruben Porras wrote: Hola, el paquete sysvinit tiene declarado al paquete «last» en el campo Conflicts y Replaces. Ya estaba así al menos desde woody. El paquete «last» no existe en woody, ni en sarge, ni sid. snapshot.d.net tampoco sabe nada. ¿Es last acaso una palabra reservada para dpkg [0] o simplemente un paquete antiguo que ya desapareció? Es claramente lo segundo, ya que dpkg no tiene palabras reservadas y last coincide con uno de los ejecutables que tiene el paquete sysvinit. Debería estar en archive.debian.org, donde se guardan las versiones históricas de Debian, pero ahora mismo no funciona (no sé cuánto tiempo llevará así). Por si te vale de algo, tengo por aquí un CD de Debian 2.0 (hamm). Es de 1998 y el paquete last ya no existía.
Re: cuentas en ftp-master
On Mon, 25 Oct 2004, Andres Seco Hernandez wrote: Hace ya algún tiempo que no subo nada a ftp-master, y despues del incidente de seguridad del año pasado no había entrado en ningún servidor de Debian. Hoy he recuperado mi clave con ese mensaje a chngpasswd y luego cambiado mi clave desde db.debian.org. Despues he ido a subir con dupload un nuevo paquete (libnet-smpp-perl, ITP enviado hace un par de dias a wnpp) y no he conseguido hacerlo contra ftp-master, así que he usado esta vez anonymous-ftp-master. Las cuentas en ftp-master ¿no coinciden con la clave con la que accedes a db.debian.org? ¿no se leen todas del mismo ldap? A people.debian.org si que entro sin problemas. Es que si no me equivoco ya no se puede entrar en ftp-master. Se cerró el acceso por lo del compromiso, y no creo que vuelva a darse de forma general.
Re: [Debconf-Es] Busco coche
On Sun, 7 Dec 2003, Jesus Climent wrote: On Sat, Dec 06, 2003 at 11:10:28PM +0100, Eric Van Buggenhaut wrote: Voy a la debconf y tengo una charla el viernes y no tengo coche. A alguien que se va el jueves por la tarde o el viernes por la mañana le queda un sitio en el automóvil ? seria interesante saber desde DONDE sales. mas que nada porque por ejemplo a Santiago Vila le vendria un poco mal pasar a por ti a barcelona ;) Pues mira por dónde, yo llevaré en mi coche a dos de Barcelona :-) (Eso sí, ellos vuelan hacia aquí primero).
Re: Libgettext...
Una aplicación (Gambas) me pide la libgettext (o algo así), pero por más que miro no parece generarse en gettext ningún paquete o fichero que tenga ese nombre. ¿Podrías decirme de qué va lo que piden? Si te refieres a libgettextpo, está en gettext-base y los .h y .a en gettext (mira los Provides:). Necesitas la versión de testing o de unstable, en woody todavía no existía. Si te refieres a libgettextlib o a libgettextsrc, son bibliotecas internas de gettext y en realidad no está contemplado que otros paquetes las usen.
Re: Dispositivos en paquetes...
On Fri, 28 Nov 2003, Ghe Rivero wrote: Tengo un pequeño problemilla con un paquetito. El upstreamer ha incluso dispositivos de ficheros directamente en él. (/usr/share.../dev/fd0 y compañia) y me da problemas tanto al descomprimirlo como al instalarlo. En la instalación, he conseguido resolver el problemilla, usando mknod en package.preinst, pero todavia no se como resolver lo otro, ya que cualquiera q lo descomprima, siempre va a darle error ya q no tiene permisos para crear tales dispositivos... Alguna idea? Reempaqueta el .orig.tar.gz y elimina de él los dispositivos. Las normas de Debian (debian-policy), que imagino que habrás leído, especifican claramente qué tipo de ficheros están permitidos y cuáles no dentro de un orig.tar.gz, y los dispositivos no lo están.
Re: Problema con upload
On Fri, 17 Oct 2003, Amaya wrote: No lo entiendo: /org/ftp.debian.org/[EMAIL PROTECTED]cat REJECT/gtodo_0.13.5-2_i386.reason Rejected: gtodo_0.13.5-2.dsc refers to gtodo_0.13.5.orig.tar.gz, but I can't find it in the queue or in the pool. El que parece que es interesante es el -1, que dice así: auric:~/incoming/REJECT$ less gtodo_0.13.5-1_i386.reason Rejected: gtodo_0.13.5.orig.tar.gz file already exists in the New directory. Y entonces uno se va al directorio /org/ftp.debian.org/queue/new y aparece esto: -rw-rw-r--1 katie 904 oct 17 05:32 gtodo_0.13.5-2_i386.changes -rw-rw1 katie 73364 oct 17 05:32 gtodo_0.13.5-2_i386.deb -rw-rw1 katie 778 oct 17 05:32 gtodo_0.13.5-2.dsc -rw-rw1 katie 26473 oct 17 05:32 gtodo_0.13.5-2.diff.gz -rw-rw1 katie 178559 oct 17 05:32 gtodo_0.13.5.orig.tar.gz -rw-rw1 katie2772 oct 17 05:32 gtodo_0.13.5-2_i386.katie que al parecer está a la espera de ser aprobado por ser un paquete nuevo desde el 9 de octubre. Lo que no entiendo es que en el campo Maintainer: no sales tú. ¿Quién hizo el ITP? :-)
Re: Fortunes no muy afortunadas ...
On Mon, 25 Aug 2003, tapia wrote: ¿De verdad crees que alguien va a pegar a su mujer solamente por haberlo leído de un proverbio chino de un fortune? Venga hombre... La cuestión no es que alguien pegue o no a su mujer por haber leído el fortune. Lo que no se puede hacer es tener la falta de respeto de hacer un chiste de ello, y ponerlo en Debian. Creo que no lo has entendio. Este fortune no habla mal de las mujeres, de quien habla mal en el fondo es de los proverbios chinos.
Re: Fortunes no muy afortunadas ...
Isaac Clerencia escribió: Por casualidad he descubierto esta fortune, que no me parece muy afortunada ...: Cuando el marido llega a la casa debe pegarle a su mujer, si él no sabe el motivo, seguramente ella si lo sabe. -- Proverbio chino. Esta gran frase pertenece al paquete fortunes-es. IMHO, debería ser retirada ... ¿qué opinais? Pues que no debería ser retirada. Incluir un refrán en una colección de refranes y citas famosas no quiere decir necesariamente que estemos de acuerdo con todo lo que dicen dichos refranes. Si vas a emprender una cruzada contra todo lo políticamente incorrecto, empieza por la Biblia (paquetes bible-kjv y bible-kjv-text). Creo que es difícil encontrar en nuestra civilización occidental un texto tan respetable y al mismo tiempo tan políticamente incorrecto. Por cierto que en la traducción yo habría puesto el marrido llega a casa (sin la) y ella sí lo sabe (con tilde). Si el encargado me lee puede considerar esto como una sugerencia.
Re: ayuda urgente para =?unknown-8bit?q?empaqu?==?unknown-8bit?q?etar_una_librer=EDa?=
On Tue, 13 May 2003, Anibal Monsalve Salazar wrote: Por favor, si usted sabe de un paquete de una librería que no use debhelper o dh_make (o cualquier otro programa similar) le estaría muy agradecido si me envia el nombre del paquete. Ya he mirado unos veinte paquetes sin exito alguno y necesito empaquetar varias librerias urgentemente. Prueba con recode. No es que sea una maravilla, pero no usa debhelper. Por cierto, library es biblioteca, no librería.
Re: [Fwd: Who's using debian?]
On Sun, 20 Oct 2002, Rudy wrote: Santiago creo que 'annoying' puede ser una buena opcion para engorroso que es como molesto, complicado. lo acabo de confirmar en el diccionario Perfecto, muchísimas gracias, la verdad es que he tenido el día bastante ocupadillo con otras cosas. Voy a decirle a Colin que considere la versión que le acabas de mandar como la última y más actualizada y que se encargue él de los errores gramaticales ingleses (he visto algunos, pero seguro que él los detecta).
Re: [Fwd: Who's using debian?]
Colin, please consider the version Rudy has just sent you as the one to be used. I just see some grammatical typos, but I'm sure you'll detect them as well. BTW: For translations I think it's better that you contact debian-l10-spanish first, since that's where all the spanish translation work is done (read: there are more available translators :-) Thanks.
Re: [Fwd: Who's using debian?]
Please note that this is a quick translation. [...] Yes, this will go on the Debian users page (http://www.debian.org/users/), so I'd like it to be high quality. Your translation is pretty good though, I think. By the way, please feel free to directly reply to the submitter to work out details! There's no particular reason for me to be an intermediary, especially given I don't speak a word of Spanish :) Most of the issues with your translation were minor English grammatical things; I can just fix these before I add it to CVS, once you've got a version you're happy with. Ok, I will try to send you an improved translation tomorrow, after I discuss with other translators about it.
Re: [Fwd: Who's using debian?]
Colin Walters wrote: Could someone translate this for me? *Approximate* translation: They are an information and entertaining center for youths who have setup a computer lab for all the young people who wants to use it. They offer not only connection to the web but also they have their own mail server, web pages for all their users, and they have short courses about Linux for those who want to start in this world. They have have 8 computers running woody and two more machines for administration purposes. These computers are dedicated to firewall, proxy, nis, nfs, dhcp, mail server, web server, database server, dns and print server. When he was proposed to setup this lab he had clear ideas about it, he has always been a debian user, which is one of the few distributions faithfull to the linux spirit, as well as offering a great amount of packages. The other distributions he tried have always been an organizational disaster. For people like him, he says, it's a very sad thing not to find things in their right place, and he never liked graphical tools to configure things, not to mention heavy upgrades which, using debian, are nearly automatic, so his choice [for debian] was clear. --- Please note that this is a quick translation. I'm sure I have made some mistakes (for example, I don't know the exact english word for engorroso :-). If you want a version to put in a public place (I mean: more public that the archives of this list :-), then please say so and we can polish the translation (if required) in the debian-l10n-spanish list before you put it somewhere else. Thanks.
Re: La vieja queja del reply-to
Julián Albo: Después de haberme confundido dos veces seguidas y enviado una respuesta al remitente y no a la lista me surge la siguiente reflexión: ¿De verdad es mejor que la lista esté configurada así? El Reply-To se considera perjudicial para la salud, pero si queréis podemos pedir que nos pongan una cabecera Mail-Followup-To. Por ejemplo mutt (según el manual) respeta dicha cabecera al usar la función list-reply (que supongo que es la que se debería usar en estos casos).
Re: nombres de los paquetes
Paco Brufal wrote: Me he bajado el source del mozilla y lo estoy compilando a mi gusto, quitando opciones. El caso es que una vez instalado el paquete, al hacer un upgrade o dist-upgrade, el apt se empeña en querer instalarme la versión original de Debian. Me gustaría que apt no me lo instale, pero sin ponerle un hold al paquete. Gracias :) No sé qué tiene de malo ponerlo en hold, pero en cualquier caso lo que puedes hacer es añadirle 1 a la época.
Re: PREGUNTA FACIL
¿Qué entiendes exactamente por pseudopaquete? Pues exactamente estos: http://www.debian.org/Bugs/pseudo-packages Lo que busco es la definición de estos paquetes, por qué se definen así. (Perdon por mi espesor...) Porque no existen (necesariamente) como paquete .deb ni te los puedes bajar haciendo apt-get install, y sin embargo pueden funcionar mal y hay un encargado de corregir las cosas que no funcionen. Por ejemplo, imagínate que descubres que el sistema de bichos no funciona bien, pues lo que se hace es enviar un informe de bicho contra el paquete bugs.debian.org explicando el problema, y así el encargado intentará corregir lo que no funcione. (No sé si es esto lo que preguntabas).
Re: usuarios especiales
Sergio Rua wrote: Tengo unas dudas a cerca de cómo hacer funcionar un paquete. El caso es que el partimage-server tiene dos modos de ejecución: demonio o interactivo. Ambos modos deben ser ejecutados como usuario 'partimag'. Para el caso del modo demonio, es muy fácil pues desde un script de /etc/init.d se llama de este modo: start-stop-daemon --stop --chuid partimag --exec $DAEMON El problema reside en el modo interactivo ya que 'partimag' es un usuario de sistema sin shell, ni home ni nada de nada. Por tanto, no se puede logear una persona como 'partimag' para luego ejecutar el comando 'partimaged'. Pues este es el problema. ¿Qué soluciones le veis? No entiendo muy bien el problema. Si quieres dar soporte en el paquete al modo interactivo, haz que el usuario partimag tenga lo que le haga falta para que se pueda; y si no quieres dar soporte a dicho modo, añade un README.Debian que lo aclare para que la gente no se líe al leer el manual.
Re: Task Spanish no existe
Javier Fernández-Sanguino Peña wrote: PD: Voy a intentar ver como puedo enviar los paquetes con el campo Task: spanish añadido y ningún cambio más a woody-proposed-updates... alguna idea de cómo hacerlo? (no me vale mails a aj o a joy). Ojo, porque los encargados de las tasks han dejado bien claro en varias ocasiones que los paquetes que pertenecen a cada tarea no es algo que decidan los encargados de los paquetes, sino que se hace mediante un mecanismo muy parecido al que existe para las prioridades y las secciones (el fichero override), es decir, con una tabla externa. No servirá de nada modificar los paquetes. No lo hagas.
Re: Dudas sobre debconf/debhelper
Juan Manuel García Molina wrote: Os escribo para ver si me aclaráis una duda que tengo. Es respecto al debconf y el debhelper. Se me ha planteado en el empaquetado de una aplicación la posibilidad de mostrar un diálogo de configuración con ncurses al estilo de debconf -creo- usando plantillas y demás. ¿Qué quieres decir con se me ha planteado? ¿Que alguien te lo ha planteado, o que te lo estás planteando tú? ¿Qué quiere decir al estilo de debconf? ¿Con debconf o sin debconf? Lo que no sé es si esto ya ha quedado obsoleto o no, y eso es lo que quiero que me aclaréis: ¿sería correcto/coherente empaquetar una aplicación a día de hoy y usar plantillas y diálogos de configuración y demás o sería mejor prescindir de estas plantillas? En el manual de la política de empaquetado de Debian no he visto nada refiriéndose explícitamente a esto, por lo que antes de meter la pata, prefiero preguntaros, que seguro que sabéis más que yo. Si vas a hacer algo que se parezca a debconf, hazlo con debconf, pues debconf existe precisamente para que la gente no tenga que reinventar la rueda. En cualquier caso debe ser posible configurar el programa cambiando lo que haga falta (a mano, con cualquier editor) en /etc. Si la duda consiste en usar debconf o no, pregúntate si el programa en cuestión tiene tantas posibilidades distintas para que sea necesario, o si por el contrario existe alguna configuración común que pueda satisfacer a todos los usuarios. Ejemplo de lo primero: Es bueno que los paquetes de X usen debconf para generar /etc/X11/XF86Config-4 porque si no lo hicieran sería imposible adivinar el tipo de tarjeta que tiene el usuario. Ejemplo de lo segundo: Es bueno que sysvinit no pregunte nada acerca de /etc/inittab porque ya hay un fichero de configuración genérico que más o menos puede servir para todo el mundo, y cuantas menos preguntas (innecesarias) haga un paquete durante la instalación, mejor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dudas sobre debconf/debhelper
Juan Manuel García Molina wrote: Se trata de un programa que para empezar a funcionar, necesita tener una base de datos y un usuario de Postgres. Por tanto, y aquí no hay problemas, el script de instalación se encarga de crear estos dos elementos. El problema ocurre al desinstalar el paquete. Tal y como está pensado, y para ser consecuente y coherente, al desinstalar con la opción «--purge» -y sólamente en ese caso-, se borran tanto el usuario de la base de datos como la propia base de datos. Y esto es lo que genera polémica. Hay gente que opina que la base de datos no debe borrarse en ningún caso y otros -entre los que me encuentro- que opinamos que si existe la creación en un momento, debe existir la operación inversa de la destrucción; si no existiera, dejaríamos basura en el sistema. Efectivamente. Un problema muy parecido se me presentó con smartlist. Si uno hace dpkg --purge smartlist ¿deben borrarse las listas de correo que se crearon? No me acuerdo de si me lo sugirió alguien, pero parecía un poco bestia que se borraran las listas creadas, así que puse una pregunta en el postrm por si acaso. Puede que no sea muy elegante, pero por otro lado tampoco es que esté uno borrando paquetes como este todos los días. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Construccion de arbol para apt
Jesás M. González-Barahona escribió: Una fácil: ¿Qué usáis para construir un árbol de directorios como le gusta a apt a partir de unos paquetes (fuente y binario)? Los paquetes son los que mantengo, y me gustaría preparar una versión beta, aptable, de varios de ellos. Por ahora, estas cosas las estoy haciendo a manubrio (incluyendo la colocación en el directorio adecuado del paquete binario y del paquete fuente, generación de Packages y Sources, y esas cosas), y no sé si hay algo que ayude, o mejor me escribo mi miniscript... Prueba apt-ftparchive. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Para construir un paquete que requiere interactuar con una BD?
Gunnar Wolf: Estoy creando un paquete que requiere interactuar con una BD, ya sea Postgres, MySQL, Oracle u otra. No quiero poner en 'Depends' a ninguna de estas bases, pues en realidad no depende de su existencia en ESTA máquina, dado que la base de datos puede estar en cualquier otro lugar... ¿Cómo procedo? No pongas nada. En mi opinión, las dependencias cliente/servidor no deberían considerarse dependencias en el sentido de dpkg. Es como si wget tuviera un Depends: httpd (o un Recommends). Sería absurdo. No me imagino a nadie instalando wget, intentando usarlo sin éxito, y enviando un bicho al BTS diciendo que si no se instala nada más no funciona adecuadamente.
Re: Para construir un paquete que requiere interactuar con una BD?
Si todavía no me crees, dime una forma de satisfacer la dependencia
A | C, A | D, B | C, B | D en la cual no suceda que estén instalados
(A y B) o (C y D), como es tu objetivo.
Bueno, actualmente tengo php4-mysql | php4-pgsql, mysql-client |
postgresql-client y me parece que es equivalente a las cuatro
combinaciones...
Pues no lo es. De esa forma es posible instalar php4-mysql para
satisfacer la primera condición y postgresql-client para satisfacer
la segunda, y dselect quedaría contento, pero eso no es lo que tú quieres.
Tú quieres que haya que instalar, o bien php4-mysql y mysql-client,
o bien php4-pgsql y postgresql-client.
Pero no, me entendiste mal - quiero justo lo contrario. Quiero que
_sólamente_ puedas instalarlo con A+B o con C+D, no con A+D ni con B+C.
Oh, señor, dame paciencia... ¡pero dámela ya!
Columna v1. Tabla de verdad de (A B) || (C D)
Columna v2. Tabla de verdad de (A || C) (A || D) (B || C) (B || D)
A B C D v1 v2
0 0 0 0 0 0
0 0 0 1 0 0
0 0 1 0 0 0
0 0 1 1 1 1
0 1 0 0 0 0
0 1 0 1 0 0
0 1 1 0 0 0
0 1 1 1 1 1
1 0 0 0 0 0
1 0 0 1 0 0
1 0 1 0 0 0
1 0 1 1 1 1
1 1 0 0 1 1
1 1 0 1 1 1
1 1 1 0 1 1
1 1 1 1 1 1
La tabla está generada con este programa:
#include stdio.h
int main() {
int A, B, C, D, v1, v2;
printf(A B C D v1 v2\n);
for (A = 0; A = 1; A++) {
for (B = 0; B = 1; B++) {
for (C = 0; C = 1; C++) {
for (D = 0; D = 1; D++) {
v1 = (A B) || (C D);
v2 = (A || C) (A || D) (B || C) (B || D);
printf(%d %d %d %d %d %d\n, A, B, C, D, v1, v2);
}
}
}
}
return 0;
}
Esto quiere decir, dado que las dos últimas columnas son siempre idénticas,
que v1 y v2 son expresiones lógicas equivalentes, que es lo que he
estado tratando de decirte desde el principio.
Si todavía te quedan dudas, compila y ejecuta tú mismo el programa,
te aseguro que no hay ningún truco.
Re: Problemilla de etiqueta
Roberto Suarez Soto: Pues entonces creo que también habría que empezar a cambiar cómo se da el Algebra, porque ahí también se usa kernel en lugar de núcleo :-) No es cierto. Yo soy matemático y uso la palabra núcleo, y que yo sepa lo mismo hace la gente de mi Departamento. Es como mozilla, se escribe ker(f) pero se pronuncia núcleo de f :-)
Re: Problemilla de C
On Thu, 14 Feb 2002, Amaya wrote: Tengo un paquete en que se llama directamente a xemacs desde el código, una barbaridad. Yo quiero que coja el valor de $EDITOR o $VISUAL (¿me dejo algo?) y lo ejecute. Qué elegantes somos las Libra :-) Pego cachito de código: [...] #define DOC_COMMAND xemacs [...] No entiendo mucho de C, apenas lo leo y lo hablo muy mal. Quiero mandar un parche a upstream y aprender algo por el camino. Yo lo que haría, de momento, es sustituir ese #define por #define DOC_COMMAND sensible-editor que está en debianutils y por lo tanto es esencial. Con eso ya te quitas de encima el pedazo de bicho que te pueden mandar. Luego, si tienes tiempo y ganas, sería cuestión de leerse lo que hay que hacer: /usr/share/doc/debian-policy/policy.html/ch-customized-programs.html donde dice 12.4 Editors and pagers, usar getenv, etc. (aunque me temo que es precisamente acerca de este etc de lo que iba tu pregunta :-).
Sobre la congelación.
Hola. Pregunta para alguien que ande por el IRC (por ejemplo Jordi :-). ¿Se sabe cómo de estricto está siendo AJ con la anunciada congelación de paquetes base?
Re: glibc6 desde fuentes [SOLUCIONADO]
Luis Taboada Rivas: ¿Es normal esto?. ¿Se debe definir la variable de entorno LINUX_SOURCE por principio, para evitar estos errores tontos cuando se compila desde los fuentes de debian? Más bien lo contrario, por principio no debería definirse ningua variable de entorno que pueda afectar a la compilación de un paquete Debian, por riesgo de que el resultado sea distinto del paquete oficial. Lo que hay que hacer es especificar correctamente las dependencias de construcción con Build-Depends. Cualquier programa que no se deje compilar después de haber instalado el paquete build-essential y los mencionados en el Build-Depends se considera erróneo y es candidato a recibir un bicho de prioridad serious (es la prioridad convenida cuando un paquete no puede compilarse a partir de su código fuente). Lo que no sé es cómo se podrá conseguir que glibc cumpla las normas si usa un kernel-headers-* distinto para cada arquitectura... Se supone que el debian/control es independiente de la arquitectura.
Re: version con ssl y sin ssl
On Mon, 22 Oct 2001, Sergio Rua wrote: Pues ahí ya me has pillado. Depende de cómo lo entiendas: el código SSL no está lincado pero sí las llamadas a la librería :-? Según RMS, no hay diferencia legal entre enlace estático o dinámico. Un programa que usa una biblioteca es un trabajo derivado de dicha biblioteca y está sujeto a la licencia correspondiente. Me sumo a los que piensan que lo mejor y sin duda lo más sencillo es añadir el soporte de SSL y ponerlo en non-US/main. Si alguien es tan tonto como para no tener la línea que hay que tener para non-US en el sources.list, allá él. non-US/main es tan parte de Debian como main.
Re: paquete de main que podria estar en main o non-US/main
Andres Seco Hernandez: Ahora solo existe kannel en main. Kannel es una pasarela wap. Supongo que lo correcto sería dejarlo en todos los sitios posibles ya que como hay gente para todo así no hay discusión de donde dejarlo ¿no? No necesariamente. En este caso lo que es correcto o no es correcto lo decides tú, que para eso eres el encargado. Si decides mover kannel a non-US y que haya un sólo kannel, puedes hacerlo perfectamente, y nadie podrá decirte que no es lo correcto. non-US (concretamente, non-US/main) no debería considerarse de segunda categoría. Es parte de Debian, igual que main. (Caso personal: unzip y zip están en non-US porque mantener dos paquetes distintos para cada uno era una *verdadera* lata).
Re: cambiar un paquete de main a non-US/main
Andrés Seco Hernández wrote: ¿como se hace para cambiar un paquete de main a non-US/main? Pues simplemente, lo pones en el incoming de nonus.debian.org y pides que se borre el de main (ya sea directamente o mediante un bug). No estaría de más mencionar el hecho en el changelog, para que los ftpmasters estén al tanto. Acuérdate de hacer dpkg-buildpackage -sa si la versión Debian no es 1, para que se incluya el .orig.tar.gz.
Re: testing o sid en un chroot
Andres Seco Hernandez: pero, realmente, el kernel que tienes corriendo es el mismo que tengas en la partición desde la que lanzas chroot, claro. ¿Es correcto usar un kernel, por ejemplo 2.2.18 o 2.2.19, para preparar paquetes y hacer pruebas en testing o sid? En general, sí. Los paquetes de lo que dependen fundamentalmente es de libc6 y otras bibliotecas, muy pocas veces del núcleo. En realidad, lo del entorno chroot es necesario solamente cuando el paquete deba depender de bibliotecas que no existen en potato. Por ejemplo, yo tengo mucha suerte y casi todos mis paquetes dependen de libc6 y nada más, así que ni siquiera me molesto en compilarlos con glibc-2.2 para ponerlos en incoming, los compilo en potato y santas pascuas. Digo yo que algunas cosas no tiran bien én un 2.2 o que hace falta 2.4 para probar otras ¿no? Para pruebas que requieran otro kernel supongo que el apaño de chroot no vale ¿no? Supongo que algún paquete habrá que no funcione, pero los paquetes que necesitan el núcleo 2.4 para funcionar son una minoría.
