El método sólo es válido en casos excepcionales muy concretos, y sabiendo muy bien lo que se está heciendo.
Normalmente modificar un paquete binario ya creado es algo que solo se debe hacer en circunstancias excepcionales, y sabiendo muy bien lo que se está haciendo. Cuando hay una dependencia en el archivo de control, no suele ser por capricho, y cambiarla alegremente lo único que va a provocar es tener un sistema inestable en el que, de forma más habitual o menos, la aplicación deje de funcionar correctamente o, lo más habitual, haya un acceso a una parte de la memoria no permitida ("Segmentation Fault") debido a que las ABI del programa y la librería no coinciden. Normalmente, y salvo que sea un caso en el que no dispongamos del paquete fuente, es mejor coger dicho paquete fuente, modificar lo que sea en él, y recompilarlo para tu plataforma con lo que se obtienen los ficheros .deb debiadamente corregidos. Es la base de todas las libertades que da el Software Libre, no veo por qué renegar de ella, no es nada difícil de hacer, da menos problemas, y en todo caso cuando sabes las consecuencias de la modificación directa en el paquete binario o precompilado, normalmente no deberías tener problemas para modificar el fuente. Lo contrario es un poco jugar a la "ruleta rusa" con el paquete.
En el caso del ejemplo que se menciona, parece muy posible que los desarrolladores de Ubuntu hayan cogido el paquete de Debian antes de su incorporación al repositorio oficial (los desarrolladores y desarrolladoras de juegos de Debian y Ubuntu trabajamos habitualmente en el mismo equipo de forma conjunta), y al haber usado el operador ~ en el número de versión hayan forzado a que sea ligeramente inferior a la que entre en Debian, de tal forma que ésta automáticamente supere a la anterior cuando se incorpore desde SID, y haber cometido algún error en este proceso con los números de versión. Ésto también ocurre, o solía ocurrir, a veces con las BinNMU (Binary Non Maintainer Upload).
El método sólo es válido en casos excepcionales muy concretos, y sabiendo muy bien lo que se está heciendo.
Normalmente modificar un paquete binario ya creado es algo que solo se debe hacer en circunstancias excepcionales, y sabiendo muy bien lo que se está haciendo. Cuando hay una dependencia en el archivo de control, no suele ser por capricho, y cambiarla alegremente lo único que va a provocar es tener un sistema inestable en el que, de forma más habitual o menos, la aplicación deje de funcionar correctamente o, lo más habitual, haya un acceso a una parte de la memoria no permitida ("Segmentation Fault") debido a que las ABI del programa y la librería no coinciden. Normalmente, y salvo que sea un caso en el que no dispongamos del paquete fuente, es mejor coger dicho paquete fuente, modificar lo que sea en él, y recompilarlo para tu plataforma con lo que se obtienen los ficheros .deb debiadamente corregidos. Es la base de todas las libertades que da el Software Libre, no veo por qué renegar de ella, no es nada difícil de hacer, da menos problemas, y en todo caso cuando sabes las consecuencias de la modificación directa en el paquete binario o precompilado, normalmente no deberías tener problemas para modificar el fuente. Lo contrario es un poco jugar a la "ruleta rusa" con el paquete.
En el caso del ejemplo que se menciona, parece muy posible que los desarrolladores de Ubuntu hayan cogido el paquete de Debian antes de su incorporación al repositorio oficial (los desarrolladores y desarrolladoras de juegos de Debian y Ubuntu trabajamos habitualmente en el mismo equipo de forma conjunta), y al haber usado el operador ~ en el número de versión hayan forzado a que sea ligeramente inferior a la que entre en Debian, de tal forma que ésta automáticamente supere a la anterior cuando se incorpore desde SID, y haber cometido algún error en este proceso con los números de versión. Ésto también ocurre, o solía ocurrir, a veces con las BinNMU (Binary Non Maintainer Upload).