Hi Simon, Here is the "really good reason" you asked for to re-introduce neofetch.
While it is true that fastfetch is the modern, actively maintained alternative, it does not cover the exact use case that a significant portion of our user base relies on. My argument for re-introduction is based on three pillars: 1. The "Legacy Migration" Factor: Many users migrating from older releases (like Debian 11 or Ubuntu 22.04) are accustomed to `neofetch`. More importantly, there are thousands of legacy scripts, dotfiles, and tutorials in the wild that explicitly call `neofetch`. Forcing them to switch to `fastfetch` breaks their workflows. Keeping neofetch allows for a seamless transition and backwards compatibility. 2. The "Emergency/Low-Level" Diagnostic Tool: Neofetch is a pure Bash script. Unlike compiled binaries (which can fail if a shared library is broken or if the graphical environment fails to load), a Bash script relies on basic system commands. If a user's system breaks, the network manager fails, or they lose their graphical interface, `neofetch` is a lifeline to quickly check kernel version, DE/WM, and hardware state without needing a browser or complex tools. It is a reliable, universal diagnostic tool. 3. My Commitment as a Maintainer: I am not asking Debian to adopt an orphaned package. I am taking full responsibility for it. As proof of my active maintenance, I am already building and maintaining this package successfully for the Fedora ecosystem (including Fedora 43, 44, and Rawhide) via COPR: https://copr.fedorainfracloud.org/coprs/daniopenhat/neofetch/ I am fully prepared to handle any downstream patches, fix compatibility issues, and ensure it meets Debian Quality Assurance standards, without adding technical debt to the archive. The community still wants it, and I am ready to do the work. I kindly ask you to reconsider this re-introduction. Best regards, Dani (Joaquín)
