Hace cinco años, los desarrolladores de Python anunciaron que dejarían de admitir Python 2 en 2020. Durante mucho tiempo, a nadie le importó y la adopción de Python 3 fue lenta. Pero las cosas han cambiado mucho últimamente ya que la fecha límite está a la vuelta de la esquina (1 de enero).
Debian está eliminando la compatibilidad con Python 2
Debian planea deshacerse de Python 2 por completo para su próxima versión estable, por lo que se están deshaciendo progresivamente del código de Python 2. Presentaron errores críticos de liberación en paquetes hoja (es decir, paquetes sin dependencias inversas) y les pidieron que se transfirieran a Python 3. Si la portabilidad de Python 3 no ocurre lo suficientemente pronto, estos paquetes se eliminarán de Debian Testing (que es lo que Kali se basa en) .
Consecuencias para Kali
Aplicaciones que desaparecen
Como Kali es una distribución continua, recibe continuamente actualizaciones de Debian Testing. Esto incluye cuando los paquetes "desaparecen" porque se han eliminado de Debian. Sin embargo, siempre pueden volver más tarde, siempre que alguien los transfiera a Python 3.
Ya hemos experimentado esto en el caso de zenmap que ya no es mantenido por los desarrolladores de nmap. Por lo tanto, ya no está construido por el paquete fuente nmap de Debian y, como resultado, ya no aparece en Kali.
Aplicaciones rotas
Tenemos muchas aplicaciones de Python 2 en Kali que usan módulos que están empaquetados en Debian. Cuando Debian lanza la versión Python 2 de dicho módulo, la aplicación se rompe en kali-dev. kali-rolling no se ve afectado por la forma en que se administra, pero la creciente divergencia entre kali-dev y kali-rolling dificulta nuestro trabajo:no recibimos actualizaciones para dichos paquetes y hay otras aplicaciones (recientes/) que probablemente requerirá nuevas versiones de esos paquetes!
Kali también debe eliminar el código de Python 2
Debido a este cambio en el ecosistema, Kali no tiene otra opción que seguir el ejemplo de Debian y eliminar también el código de Python 2. Este gran esfuerzo se rastrea con muchos problemas de GitLab en todos los paquetes que dependen de Python 2 de alguna manera. Ya hemos presentado informes de errores ascendentes para todos los paquetes en los que todavía no hay compatibilidad con Python 3.
La forma en que manejamos cada caso depende de muchos factores:
- Si upstream está trabajando en la compatibilidad con Python 3, solo esperamos hasta que esté listo.
- Si upstream está inactivo o no está interesado en migrar su código a Python 3, tenemos pocas opciones:
- o eliminamos el paquete;
- o encontramos alguna bifurcación/parche que agrega compatibilidad con Python 3;
- o hacemos el trabajo de portabilidad nosotros mismos (bastante improbable excepto para scripts triviales).
También depende del tipo de paquetes:
- Para una biblioteca de Python, es un proceso de dos pasos:primero agregamos compatibilidad con Python 3; La compatibilidad con Python 2 se elimina más adelante, una vez que todas las dependencias inversas se han actualizado para usar Python 3.
- Para una aplicación de Python, una sola actualización puede ser suficiente, pero esa actualización puede depender de que las dependencias se transfieran primero a Python 3.
No nos gusta eliminar el software, pero a veces, cuando ya no se les da mantenimiento, no tenemos otras opciones. Para paquetes importantes, estamos esperando más tiempo, lo que le da más tiempo a la comunidad para agregar el soporte requerido de Python 3. Incluso podríamos parchearlos para que muestren una advertencia invitando a los usuarios a contribuir, o al menos entender que la aplicación puede eliminarse en un futuro cercano.
Para los paquetes que ya no agregan mucho valor o que tienen alternativas viables en Kali, es posible que los eliminemos en cualquier momento.
Cómo puedes contribuir
Si una de sus aplicaciones favoritas aparece entre los paquetes de Kali afectados o entre los paquetes afectados del equipo de seguridad de pkg de Debian, entonces debe revisar su situación y posiblemente ayudar a los desarrolladores ascendentes enviando una solicitud de extracción agregando compatibilidad con Python 3. Incluso si upstream no está muy activo, podremos fusionar sus cambios en Kali y mantener el paquete por más tiempo hasta que upstream vuelva a estar activo.
Si no tiene las habilidades de codificación requeridas para esto, aún puede intentar encontrar una bifurcación/parche de Python 3 escrito por otra persona e indicárnoslo en el problema de GitLab correspondiente o en el informe de error de Debian. O dígales a los desarrolladores cuánto le gusta su aplicación y que le gustaría seguir usándola, por lo que deberían migrar a Python 3.