El blog de Javier Aranda

Brevemente explicaré como configuro un repositorio Git remoto donde almacenar una copia de mi repositorio local. Existen varias formar de hacerlo, por lo que si quieres ampliar la información te recomiendo la lectura del capítulo dedicado a ello del libro ProGit. Y si no tienes inconveniente en que tu repositorio sea público y no esté en tu servidor, os recomiendo el uso de Github.

1. Requisitos

Para poder disponer de nuestro repositorio remoto necesitamos:

a) Estar en posesión obviamente de un servidor dedicado, vps o cualquier servicio con acceso ssh (no tiene por que ser root).

b) Que el servidor tenga instalado Git (o si tenemos acceso root instalarlo nosotros mismos)

2. Creación del repositorio remoto en tu servidor

a) Entramos bajo el usuario con el que vayamos a conectarnos normalmente para realizar las actualizaciones (si queremos podemos crear tantos usuarios linux como desarrolladores tengamos, aunque git es independiente en eso pues lo que cuenta es los datos del commiteador y no del usuario ssh con el que nos hayamos conectado). Supongamos que utilizaremos el usuario desarrollo cuyo directorio es /home/desarrollo.

$ ssh desarrollo@git.example.com

b) Creamos el directorio donde se guardará el repositorio y lo inicializamos como un repositorio de git sin área de trabajo (ya que no la vamos a utilizar pues no trabajamos desde el servidor, así que sólo necesitamos guardar los archivos del control de versiones propios de git).

$ mkdir -p git/proyecto1.git
$ cd git/proyecto1.git
$ git init --bare

Si este proceso lo hiciéramos bajo root, no debemos olvidarnos de cambiar el propietario de este directorio por el usuario desde el cual vayamos a conectarnos a ssh para realizar las operaciones de git.

3. Creación del repositorio local

Si ya tuvieramos un repositorio creado, pasar al paso siguiente.

Para crear un repositorio sólo tenemos que irnos al directorio de trabajo e inicializar un repositorio:

$ cd ~/mis_proyectos
$ mkdir proyecto1
$ cd proyecto1
$ git init

4. Añadir el repositorio remoto a nuestro repositorio local

Para que la sincronización pueda llevarse a cabo, debemos añadir nuestro repositorio remoto:

$ git remote add origin ssh://desarrollo@git.example.com/home/desarrollo/git/proyecto1.git

5. Crear y/o subir el contenido al servidor remoto

Si no tenemos contenido creado, deberemos crear alguno para poder subirlo:

$ touch README
$ git add README
$ git commit -m 'mi primer commit'

Y ahora subimos los cambios al servidor con:

$ git push origin master

5. Clonando el repositorio remoto

Si desde otro equipo deseamos obtener nuestro código, sólo tenemos que clonar el repositorio:

$ git clone ssh://desarrollo@git.example.com/home/desarrollo/git/proyecto1.git

Tras un periodo de exámenes, continúo escribiendo este tutorial.

Descripción de modsms

Como ya se ha comentado en entradas anteriores, vamos a realizar un módulo de actividad muy sencillo llamado modsms que nos permitirá tratar todos los aspectos básicos a tener en cuenta a la hora de desarrollar nuestro módulo. Este módulo hará uso de una base de datos para almacenar una serie de mensajes breves escritos por los alumnos (como un chat aunque sin una actualización en tiempo real) que responden a una pregunta del profesor. El diseño relacional de la base de datos queda de la siguiente forma:

Esquema Entidad-Relación modSMS

De color azul tenemos las tablas creadas por este módulo, y de color rosa las ya existentes en moodle pero que son referenciadas desde las nuestras.

Definición de las tablas: db/install.xml

El primer archivo que vamos a crear en nuestro módulo es el archivo de definición de las tablas que se usarán en nuestro módulo y que se crearán cuando lo activemos/instalemos. Este archivo es necesario crearlo aunque no usemos en nuestro módulo nada de las bases de datos, pero, como veremos más adelante, siempre resulta necesario crear una tabla con el nombre de nuestro módulo donde se almacenarán las distintas instancias de nuestro módulo en los cursos.

Este archivo contiene una definición de las tablas en un formato XMLDB modificado por moodle a su manera, por lo que si usamos algún editor existente que soporte ese xml deberemos prestar atención a los cambios. Para facilitarnos esa tarea, el propio moodle lleva incorporado un editor web que es el que usaremos para crear el esquema. Para ello, crearemos la estructura inicial del módulo creando la carpeta modsms bajo raiz-de-moodle/mood, dentro de ella la carpeta db y dentro de esta un archivo de texto llamado install.xml.

El primer paso es dotar de contenido a este archivo con una estructura básica para que el editor de moodle pueda reconocerlo y editarlo:

Como puede observarse, el xml consta de dos partes: la definición de tablas (tables) y la definición de consultas (statements). Por ahora nos olvidaremos de esta última parte y nos centraremos en la primera, la cual define la tabla principal del módulo (modsms) con un único campo (id) que identifica cada instancia de nuestro módulo de forma única.

Ahora entramos como administrador en moodle y en el menú de administración seleccionamos Miscelánea > XMLDB Editor. Una vez estemos en la página, buscamos la línea mod/modsms/db y pulsamos sobre Load, lo cual cargará nuestro archivo xml para su edición. Una vez cargado, en la misma línea tendremos activada la opción de editar (Edit), y pulsando sobre ella accederemos a la interfaz de edición del xmldb.

Vista de la interfaz de edición de XMLDB

Creando la estructura de las tablas

Como puede apreciarse en la página de edición, disponemos ya de una tabla creada, llamada modsms, que se corresponde con la única tabla obligatoria para un módulo de actividad en moodle. En esta tabla se creará un registro/fila/tupla por cada una de las instancias de nuestra actividad en cualquier curso de todo moodle. Y… ¿qué es una instancia? Pues es simplemente una actividad que insertamos en algún curso, que se diferencia de otras instancias de la misma actividad por un número de identificación único que se guarda en la tabla como el campo id. Esta tabla debe contener obligatoriamente tres campos: id, course y name, que identifican de forma unica cada instancia, hace referencia al curso donde está y el nombre que tiene, respectivamente. Para editar la tabla solamente pulsaremos sobre el enlace [Edit] que se encuentra junto al nombre de la tabla bajo la sección Tables.

Como se observa, la tabla ya contiene el campo id mencionado anteriormente. Ahora es el turno de añadir los demás campos que necesitamos en base al diseño realizado arriba. Para añadir un nuevo campo, sólo hay que pulsar sobre [New Field] y rellenar los datos del campo en la siguiente página. En el caso del campo course, el formulario lucirá el siguiente aspecto:

Editando el campo course

Repetiremos este proceso hasta completar todos los campos de la tabla. Es importante que todos los campos tengan la restricción de no nulo (NOT NULL), ya que ninguno debe ser nulo para el correcto funcionamiento del módulo. Una vez creados todos los campos, el siguiente paso es aplicar las restricciones y las relaciones a los campos que lo requieran. En esta tabla, deberemos reflejar que el campo course es una clave foránea (hace referencia a) del campo id en la tabla course. Para informar de esto a la base de datos, pulsamos sobre [New Key] y rellenamos los datos:

Editando las restricciones de clave foranea

Usando el enlace [Back] volvemos hacia atrás hasta llegar a la página que muestra la lista de tablas creadas (solo hay una por el momento). Si pulsamos sobre el enlace [New Table] nos mostrará la interfaz de creación de tablas dónde sólo hay que darle un nombre y el comentario es opcional, y la aplicación se encargará de crear el campo identificativo por defecto (id). En este paso creamos la tabla de nombre modsms_messages donde guardar los mensajes escritos por los alumnos. Y repetimos los pasos anteriores para dotar de contenido a esta nueva tabla.

Guardando el nuevo archivo

Por razones que desconozco, pese a contar el archivo con permisos 777 en linux, resulta imposible guardarlo desde moodle con la opción [Save] que aparece junto a la ruta en la lista de archivos editables de la interfaz de edición de xmldb. Por ello, la única manera de guardar los cambios es, estando en la interfaz de edición, pulsar sobre [View Edited] con el botón derecho del ratón y darle a Guardar como…, sustituyendo el antiguo archivo por este nuevo.

Cuando todo esté terminado, el contenido del archivo install.xml debe ser muy parecido a este:

Nota sobre los nombres de tablas y campos

En moodle, el nombre de la tabla principal de un módulo debe llamarse igual que este, y las demás tablas que necesitemos deben empezar por el nombre del módulo. En nuestro caso, el módulo se llama modsms, su tabla principal modsms y la otra que necesitamos modsms_messages.

Si en una tabla hacemos referencia al campo de otra tabla, este campo deberá llamarse de la forma nombredelatablanombredelcampo. Así, para hacer referencia al campo id de la tabla user, en nuestra tabla modsms_messages hemos creado un campo llamado userid.

Todos estos requerimientos pueden consultarse en la documentación en inglés sobre las bases de datos en moodle.

Las bases de datos relacionales, como MySQL, PostgreSQL y varios productos comerciales, nos han servido bien durante muchos años. Últimamente, sin embargo, ha habido mucha discusión sobre si el modelo relacional está llegando al final de su vida útil, y qué es lo que viene después de él.

¿Qué motor de base de datos debería usar?

Por supuesto, la respuesta es “depende”, pero esto no resulta de mucha ayuda. Déjame hacerte algunas preguntas para ayudarte a averiguar que tecnología es la apropiada para tu aplicación particular. Entonces, podré darte algunos consejos para que puedas conocer más.

Ante todo, calma. Lo más probable es que la base de datos que uses actualmente funcione perfectamente bien por ahora. Pero es posible que quieras estar atento en caso de que note algunos de los síntomas que avisan que el modelo relacional está trabajando al límite. Algunos síntomas relacionados con la estructura de tus datos:

• ¿Tienes tablas con varias columnas, y sólo algunas de ellas son actualmente usadas por una fila en particular?
• ¿Tienes tablas atributo donde cada fila es

(clave foránea a una fila de otra tabla, nombre del atributo, valor del atributo)

y necesitas hacer feos joins en tus consultas para tratar con esas tablas?

• ¿Has dejado de utilizar columnas para los datos estructurados, y en su lugar los serializar (a JSON, YAML, XML y otros) y almacenas la cadena resultante en tu base de datos?
• ¿Tiene tu esquema un gran número de tablas de unión muchos-a-muchos o estructuras tipo árbol (una clave foránea que hace referencia a una fila diferente de la misma tabla)?
• ¿Encuentras que con frecuencia tienes que hacer cambios en tu esquema para poder representar adecuadamente los datos de entrada?

Otros síntomas relacionados con la escalabilidad de tu sistema:

• ¿Estás alcanzando el límite de la capacidad de escritura con un sólo servidor? (Si tu problema es la capacidad de lectura, deberías establecer una replicación maestro-esclavo. Así mismo, asegurate que primero has puesto la base de datos en el servidor mas potente que puedas pagar, de que has optimizado tus consultas y que tu esquema no pueda dividirse fácilmente en fragmentos.
• ¿Tu cantidad de datos es mayor que la que un sólo servidor puede manejar?
• ¿La carga de tus páginas se ralentizan inaceptablemente por procesamientos en lote en segundo plano sobre la inmensa base de datos?

En mi opinión, se pone demasiado énfasis en la escalabilidad, a pesar de ser un problema muy lejano en la mayoría de los proyectos. Es comprensible – los sistemas a gran escala son sexis, y a todo el mundo le gusta pensar que están creando un servicio el cual va a ser muy popular – pero en la mayoría de las veces, los desarrolladores deberían centrarse en las necesidades de sus clientes, y resolver los problemas de escalabilidad sólo si realmente estos aparecen.

Dicho esto, hay una razón más para considerar las bases de datos no relacionales: están de moda. Es una idea tonta basar una decisión técnica en una moda, pero recuerda el aspecto humano de los proyectos de gestión de software. Los desarrolladores en general queremos trabajar con gente guay en un ambiente guay y usando tecnología guay. Eso significa que si quieres contratar desarrolladores y les proporcionas todo este ambiente guay, tendrás una mejor oportunidad de conseguir a los mejores. La moda no debería ser la razón principal, pero si todo lo demás es igual, probablemente puedes tirar por el lado guay. Y ahora voy a dejar de decir guay – no es muy guay.

Bases de datos documentales y la Big Table

Este artículo sobre la BigTable describe cómo Google ha desarrollado su propia base de datos altamente escalable para uso interno, como base de varios de sus servicios. El modelo de datos es un poco diferente del relacional: las columnas no necesitan ser predefinidas, y cada fila se puede agregar con cualquier conjunto de columnas. Las columnas vacías no se almacenan en absoluto.

La BigTable ha inspirado a muchos desarrolladores a escribir su propia implementación de este modelo de datos, dónde los más populares son HBase, Hypertable y Cassandra. La falta de un esquema predefinido pueden hacer atractivas estas bases de datos en aplicaciones dónde los atributos de los objectos no son conocidos de antemano, o cambian con frecuencia.

Las bases de datos documentales poseen un modelo de datos relacionado (aunque la forma en que manejan la concurrencia y los servidores distribuidos puede ser un poco diferente): una fila en la BigTable con un número arbitrario de columnas/atributos se corresponde a un documento en una base de datos documental, que normalmente es un árbol de objetos conteniendo los valores de los atributos y listas, a menudo mapeadas a JSON o XML. Bases de datos documentales de código abierto son Project Voldemort, CouchDB, MongoDB, ThruDB y Jackrabbit.

¿Y cuál es la diferencia con almacenar cadenas JSON en MySQL? Las bases de datos documentales pueden actualmente trabajar con la estructura de los documentos, por ejemplo extrayendo, indexando, añadiendo y filtrando datos basado en el valor de un atributo dentro de los documentos. Alternativamente, tu puedes por supuesto crear la indexación de los atributos por ti mismo, pero yo no lo recomendaría a menos que esto te haga trabajar con tu código antiguo más fácilmente.

La gran limitación de las bases de datos del tipo BigTable y las documentales es que la mayoría de las implementaciones no pueden realizar uniones (joins) u operaciones de expansión entre varias filas o documentos. Esta restricción es deliberada, porque permite a la base de datos el particionado automático, el cual es importante para escalar — véase la sección de almacenamiento distribuido de parejas de clave-valor a continuación. Si la estructura de tus datos es una gran cantidad de documentos independientes, esto no es un problema — pero si tus datos se acojen a un modelo relacional y necesitas hacer uniones, por favor, no intentes forzarlo a un modelo documental.

Bases de datos de gráfos

Las bases de datos de gráfos residen en el extremo contrario del espectro. Mientras las documentales son buenas para almacenar datos estructurados en la forma de muchos documentos independientes, las basadas en gráfos se centran en las relaciones entre los elementos — un mejor ajuste para los modelos de datos altamente conectados.

El SQL estándar no permite consultar las relaciones transitivas, es decir, un encadenamiento de longitud variable entre varias uniones que continúan hasta que algún tipo de condición se cumple. Las bases de datos de gráfos están optimizadas precisamente para este tipo de datos. Estos síntomas indican que sus datos encajarían mejor en un modelo gráfico:

• Escribes grandes cadenas de uniones (unión de la tabla A con la B, B con C, C con D …) en tus consultas.
• Escribe bucles de consultas en tu aplicación para conseguir una cadena de relaciones (particularmente cuando no sabes de antemano la longitud que tomará el encadenamiento).
• Tienes varias uniones muchos-a-muchos o estructuras tipo árbol.
• Tus datos ya están en una forma gráfica (por ejemplo la información sobre quién es amigo de quién en una red social).

Hay menos opciones en las bases de datos gráficas que documentales: Neo4j, AllegroGraph y Sesame (que normalmente utiliza MySQL o PostgreSQL como back-end) son las que mirar. FreeBase y DirectEdge han desarrollado bases de datos gráficas para su uso interno.

Las bases de datos gráficas se asocian a menudo con la web semántica y almacenes de datos RDF, que es una de las aplicaciones para las que son usadas. Realmente creo que muchos datos de otras aplicaciones estarían bien representados en gráfos. Sin embargo, como ántes, no trates de forzar  los datos en un gráfo si encajan mejor en tablas o documentos.

MapReduce

Muy a la ligera: si el procesamiento por lotes en segundo plano es tu problema y no conoce el modelo MapReduce, debería. Popularizado por otro artículo de Google, MapReduce es una forma de escribir trabajos de procesamiento por lotes sin preocuparse por la infraestructura. Diferentes bases de datos se prestan mejor o peor al MapReduce — algo a tener en cuenta al elegir una base de datos para satisfacer nuestras necesidades.

Hadoop es el rey entre las implementaciones de código abierto, aunque también merece la pena mirar Skynet y Disco. CouchDB también incluye algunas ideas de MapReduce en una menor escala.

Almacenamiento distribuido de clave-valor

Un almacenamiento de clave-valor es un concepto muy simple, muy similar a una tabla hash: puedes recuperar un elemento basado en su clave, puedes insertar un par de clave-valor, y puedes borrar un par de clave-valor. El valor puede ser simplemente una lista opaca de bytes, o puede ser un documento estructurado (la mayoría de las implementaciones de bases de datos documentales o basadas en la BigTable se pueden considerar como almacenamientos clave-valor).

Las bases de datos documentales, gráficas y MapReduce introducen nuevos modelos de datos y nuevas formas de pensar que pueden ser útiles incluso en una aplicación de pequeña escala; no necesitas ser Google o Facebook para beneficiarte de ellas. El almacenamiento distribuido de clave-valor, por otra parte, va en realidad acorde con la escalabilidad. Pueden escalar cantidades verdaderamente enormes de datos — muchos más de los que un sólo servidor podría soportar.

Las bases de datos distribuidas pueden transparentemente particionar y replicar tus datos a través de varias máquinas en un clúster. No resulta necesario implementar un sistema de fragmentación para decidir sobre qué determinado servidor se puede encontrar un determinado fragmento de datos; la base de datos lo hace por usted. Si un servidor muere, no hay problema — otros pueden inmediatamente empezar a funcionar. Si necesita más recursos, sólo tiene que añadir los servidores al clúster, y la base de datos le asignará automáticamente una parte de los datos y de la carga.

Al elegir un almacenamiento de clave-valor, debes decidir entre si debe estar optimizado para una baja latencia (para un rápido acceso durante el ciclo de petición-respuesta típico de un servidor web) o para un rendimiento alto (usado en los trabajos de procesamiento por lotes).

Aparte de las basadas en la BigTable y las documentales, Scalaris, Dynomite and Ringo proporcionan cierta garantía en la consistencia de los datos, mientras que se encargan del particionamiento y la distribución del conjunto de datos. MemcacheDB y Tokyo Cabinet (con Tokyo Tyrant para el servicio en red y LightCloud para que sea distribuida) se centran en la latencia.

La advertencia sobre la limitación en las transacciones y las uniones se aplica incluso más fuertemente en las bases de datos distribuidas. Implementaciones diferentes tienen enfoques distintos, pero en general, si necesitas leer varios elementos, manipularlos de alguna manera y luego volver a escribirlos, no existe garantía de que va a terminar en un estado coherente inmediatamente (aunque muchas implementaciones tratan de convertirse eventualmente consistentes resolviendo conflictos de escritura o usando protocolos de transacciones distribuidas; véase el algoritmo de Amazon Dynamo para un ejemplo). Por lo tanto, sólo deberías utilizar estas bases de datos si tus datos son elementos independientes, y si la disponibilidad y performancia son más importantes que las propiedades ACID. Para más información, lea acerca del Teorema CAP de Brewer, que establece que entre la consistencia, la disponibilidad y el particionado, sólo podemos elegir dos, y nunca ninguna base de datos podrá saltarse este hecho.

Richard Jones, co-fundador de Last.fm, ha escrito una excelente visión de conjunto de los almacenamientos de clave-valor. También, Tony Bain ofrece una introducción a las diferencias conceptuales entre las bases de datos relacionales y los almacenamientos de clave-valor, y recientemente hubo un evento NOSQL en San Francisco, donde se presentaron una serie de diferentes bases de datos no relacionales.

Los sistemas distribuidos son poco amistosos… muy poco amistosos. Sugiero que se usen sólo si realmente necesitamos los aspectos de escalado que ofrecen (o sólo por diversión fuera de un entorno de producción).

Resumiendo

En este artículo me he centrado en proyectos de código abierto. Si usted está dispuesto a usar a un determinado proveedor de alojamiento, vale la pena considerar Google Datastore, Amazon SimpleDB, Windows Azure Storage Services o Force.com. Son tecnologías buenas, pero tenga en cuenta el riesgo potencial de los negocios cerrados.

No puedo hacer juicios sobre la idoneidad de determinados proyectos para fines particulares. Hay varias aplicaciones muy decentes, pero también hay algunas aplicaciones nuevas y muy inestables. Si vas a considerar el uso de alguna de ellas, deberás realizar tu propia investigación:

• Buscar en el sitio web del proyecto una lista de sitios que utilizan la base de datos en producción (y en qué aspecto de su servicio lo utilizan).
• Comprobar si tienen una comunidad de código abierto activa, para el caso que el desarrollador original pierda el interés y deje de mantener el software.
• Tratar de encontrar algún punto de referencia (aunque ten en cuenta que muchos puntos de referencia publicados en la web usan métodos defectuosos y/o anticuados, por lo que si buscas seriedad deberás ejecutar tus propias pruebas, usando datos que coinciden con las características de tu aplicación).

Y como pasa con cualquier tema de moda, hay muchas personas con opiniones fuertes, tanto positivas como negativas, no te dejes influenciar por ellos. Espero haberte dado una visión general de los tipos de cosas que puedes hacer con diferentes tipos de bases de datos para que puedas elegir el más adecuado a tu aplicación.

Fotografía por flickr.com/photos/vermininc

Traducción libre del texto original Should you go Beyond Relational Databases? by Martin Kleppmann

Si queremos manipular imágenes desde nuestro script php podemos usar varias librerías gráficas para ello (GD, ImageMagick, Netpbm…) aunque sin lugar a dudas la más utilizada en la primera de ellas, librería desarrollada por la gente de boutell.com y que actualmente va por la versión 2, la cual incluye muchas mejoras respecto a la 1. Pero, a pesar de esas mejoras, todavía posee algunas carencias que nos harían la vida más fácil. En este contexto, los desarrolladores de PHP deciden realizar un fork (clon) de la librería original de Boutell y comienzan a incorporarle numerosas funciones nuevas: es lo que se conoce como la librería GD Bundled (empaquetada, que va con php).

Esto no tendría nada de malo si no fuera porque algunas distribuciones de Linux (en concreto Debian y sus derivadas como Ubuntu) consideran que esta nueva librería puede ser inestable y contener errores y deciden no incluirla en los binarios disponibles en el sistema de paquetes de la distribución. De esta forma, cuando instalamos el paquete php5-gd estamos instalando la librería original de Boutell, y por tanto, no dispondremos de las nuevas funciones que incorpora la versión de la gente de php.

¿Y cuál es la solución? Pues recompilar el binario de la librería GD.

El primer paso es instalar todos los paquetes necesarios y el código fuente de php:

apt-get install build-essential debhelper fakeroot

# el codigo fuente debe residir en /usr/src
cd /usr/src

# descargar el código fuente de php
apt-get source php5

# instalar todos los paquetes necesarios para compilar php5
apt-get build-dep php5

# acceder al directorio del código (puede variar según la versión disponible)
cd php5-5.2.6.dfsg.1

La forma de la cual debe compilarse un paquete se establece dentro de archivos bajo el directorio debian de un paquete. Las reglas que configuran el proceso de compilación se encuentran en debian/rules. Dentro de este archivo, en una línea, se puede leer –with-gd=shared,/usr –enable-gd-native-ttf \. Esta línea le dice al compilador que debe linkear con la librería LibGD distribuida con Ubuntu como librería compartida. Lo único que deberemos hacer es reemplazar esa linea por –with-gd=shared –enable-gd-native-ttf \. Esto hace que el proceso de compilación use la versión GD de php y cree una librería compartida con ella.

Una vez que el paquete ha sido reconfigurado, podemos proceder a su compilación y posterior instalación:

#debemos situarnos dentro del directorio del código fuente de php o la compilación no funcionará
cd /usr/src/php5-5.2.6.dfsg.1

# crear los paquetes php5-*
dpkg-buildpackage -rfakeroot

# instalar el nuevo paquete php5-gd
cd ..
dpkg -i php5-gd_5.2.6.dfsg.1-3ubuntu4.1_i386.deb

La compilación durará varios minutos (alrededor de 20 con un Core2Quad). Una vez realizado esto ya sólo tenemos que reiniciar Apache y ya podemos usar las nuevas funciones de la librería GD Bundled. Existe un único problema: si actualizamos Ubuntu reinstalaremos el paquete oficial y dejaremos de tener disponible la nueva librería. Para los que lo usen en una Ubuntu normal con interfaz gráfica, cada vez que encendamos el ordenador nos avisará de que hay actualizaciones disponibles. Hay que estar pendientes y desmarcar la casilla del paquete php5-gd. Otra posible solución a este problema pasa por instalar la librería desde los repositorios de dotdeb.org.

Vía CuMu.Li