Il y a cinq ans, les développeurs Python ont annoncé qu'ils cesseraient de prendre en charge Python 2 en 2020. Pendant longtemps, personne ne s'en souciait et l'adoption de Python 3 était lente. Mais les choses ont beaucoup changé ces derniers temps car la date limite approche à grands pas (1er janvier).
Debian supprime la prise en charge de Python 2
Debian prévoit de se débarrasser entièrement de Python 2 pour sa prochaine version stable afin de se débarrasser progressivement du code Python 2. Ils ont déposé des bogues critiques sur les paquets feuilles (c'est-à-dire des paquets sans dépendances inverses) en leur demandant d'être portés sur Python 3. Si le port Python 3 n'arrive pas assez tôt, ces paquets seront supprimés de Debian Testing (ce qui est ce que Kali est basé sur) .
Conséquences pour Kali
Applications qui disparaissent
Comme Kali est une distribution continue, elle reçoit en permanence des mises à jour de Debian Testing. Cela inclut lorsque des paquets « disparaissent » parce qu'ils ont été supprimés de Debian. Cependant, ils peuvent toujours revenir plus tard, à condition que quelqu'un les porte sur Python 3.
Nous en avons déjà fait l'expérience dans le cas de zenmap qui n'est plus maintenu par les développeurs de nmap. Ainsi, il n'est plus construit par le paquet source nmap de Debian et, par conséquent, n'apparaît plus dans Kali.
Applications cassées
Nous avons de nombreuses applications Python 2 dans Kali qui utilisent des modules empaquetés dans Debian. Lorsque Debian abandonne la version Python 2 d'un tel module, l'application est cassée dans kali-dev. kali-rolling n'est pas affecté en raison de la façon dont il est géré, mais la divergence croissante entre kali-dev et kali-rolling rend notre travail plus difficile :nous ne recevons pas de mises à jour pour ces packages et il existe d'autres applications (récentes/) qui nécessitera probablement de nouvelles versions de ces packages !
Kali doit également supprimer le code Python 2
En raison de ce changement dans l'écosystème, Kali n'a d'autre choix que de suivre l'exemple de Debian et de supprimer également le code Python 2. Cet effort géant est suivi de nombreux problèmes GitLab contre tous les packages dépendant de Python 2 d'une manière ou d'une autre. Nous avons déjà déposé des rapports de bogues en amont pour tous les packages pour lesquels il n'y a pas encore de prise en charge de Python 3.
La manière dont nous traitons chaque cas dépend de nombreux facteurs :
- Si l'amont travaille sur la prise en charge de Python 3, nous attendons simplement qu'il soit prêt.
- Si l'amont est inactif ou n'est pas intéressé par le portage de son code vers Python 3, nous n'avons alors que peu de choix :
- soit nous supprimons le colis ;
- ou nous trouvons un fork/patch qui ajoute la prise en charge de Python 3 ;
- ou nous effectuons le travail de portage nous-mêmes (plutôt peu probable, sauf pour les scripts triviaux).
Cela dépend aussi du type de packages :
- Pour une bibliothèque Python, il s'agit d'un processus en deux étapes :nous ajoutons d'abord la prise en charge de Python 3 ; La prise en charge de Python 2 est supprimée ultérieurement, une fois que toutes les dépendances inverses ont été mises à jour pour utiliser Python 3.
- Pour une application Python, une seule mise à jour peut suffire, mais cette mise à jour peut dépendre du portage préalable des dépendances vers Python 3.
Nous n'aimons pas supprimer des logiciels, mais parfois, lorsqu'ils ne sont plus maintenus, nous n'avons pas d'autre choix. Pour les packages importants, nous attendons plus longtemps, laissant ainsi plus de temps à la communauté pour ajouter le support Python 3 requis. Nous pourrions même les corriger afin qu'ils affichent un avertissement invitant les utilisateurs à contribuer, ou au moins comprendre que l'application pourrait être supprimée dans un proche avenir.
Pour les packages qui n'ajoutent plus beaucoup de valeur ou qui ont des alternatives viables dans Kali, nous pouvons les supprimer à tout moment.
Comment vous pouvez contribuer
Si l'une de vos applications préférées apparaît parmi les packages Kali concernés ou parmi les packages concernés de l'équipe pkg-security de Debian, vous devez alors examiner sa situation et éventuellement aider le ou les développeurs en amont en soumettant une demande d'extraction ajoutant la prise en charge de Python 3. Même si l'amont n'est pas très actif, nous pourrons fusionner vos modifications dans Kali et conserver le paquet plus longtemps jusqu'à ce que l'amont redevienne actif.
Si vous n'avez pas les compétences de codage requises pour cela, vous pouvez toujours essayer de trouver un fork/correctif Python 3 écrit par quelqu'un d'autre et nous le signaler dans le problème GitLab correspondant ou le rapport de bogue Debian. Ou, dites aux développeurs à quel point vous aimez leur application et que vous aimeriez continuer à l'utiliser, afin qu'ils la transfèrent vers Python 3.