aptitude, / etc / alternatives / aptitude, enlace simbólico y aptitude-curses

A veces, cuando estoy ejecutando aptitude me encuentro con problemas (no me malinterpreten, me encanta aptitude, especialmente el cliente de CLI, siempre me he preguntado por qué existe / etc / alternatives / aptitude.

Sé para qué / etc / alternatives se utilizan, vinculando simbólicamente uno o más progtwigs que hacen lo mismo. Por ejemplo, apt, aptitude, apt-get y wajig hacen lo mismo. Lo que no entiendo es por qué se usa esa estructura. Estoy ejecutando Debian Buster pero sería y era lo mismo en Debian estable e incluso antes.

https://debian-handbook.info/browse/stable/sect.customizing-graphical-interface.html

┌─[shirish@debian] - [~] - [10012] └─[$] which aptitude /usr/bin/aptitude ┌─[shirish@debian] - [~] - [10013] └─[$] ll -h /usr/bin/aptitude lrwxrwxrwx 1 root root 26 2013-07-25 22:05 /usr/bin/aptitude -> /etc/alternatives/aptitude ┌─[shirish@debian] - [~] - [10014] └─[$] ll -h /etc/alternatives/aptitude lrwxrwxrwx 1 root root 24 2013-07-25 22:05 /etc/alternatives/aptitude -> /usr/bin/aptitude-curses 

Si bien puedo entender cómo fluye la relación de uno a otro, no entiendo por qué todavía existe / etc / alternatives / aptitude?

¿No podríamos simplemente tener aptitude enlazado a aptitude curses? No veo que ocurra ninguna rotura si se hacía ese path. Además, si no me equivoco, la mayoría o todos los administradores del sistema estarían agregando / agregando aptitude a la mezcla y no aptitude-curses.

Esperando saber más.

Este es un remanente de versiones pasadas de aptitude que tenía una versión experimental aptitude-gtk , disponible como alternativa.

Esto se eliminó en la versión 0.6.6-1, en 2012. Aunque ya no es útil, mantener la alternativa no hace daño y es más fácil que tratar de migrar correctamente a un binary no alternativo.