Distributions May Fail to Package Neofetch Updates

[MingcongBai]

What happened?

I was made aware of a pull request that added a small logo for AOSC OS/Retro. Given that the original upstream at @dylanaraps is no longer active, you have duplicated and merged pull request here and suggested that...

"HyFetch is a fork of neofetch with LGBTQ pride flags, but the repo also serves as an updated version of neofetch, addressing many pull requests that are not merged in the original repo."

First of all, thank you. However, I have only then found out about the fact that a copy of Neofetch is maintained here in this repository. Good news, right? Not quite.

Hyfetch, as technically a wrapper project for Neofetch, is not Neofetch. However, judging from the release history, it seems that instead Neofetch is considered one of Hyfetch's integral components.

What's the problem?

Consider this. Various distributions has packaged Neofetch, whose version stopped at 7.1.0, reflecting only changes in Neofetch. Now, Hyfetch merges Neofetch as a component and reset the version history. What kinds of problems might this cause?

1. Visibility. Practically no distribution knows of an updated fork for Neofetch. Repology statistics demonstrates this point perfectly. Neofetch is currently sitting at 7.3.3 (but not reflected in either commit history or tags).
2. Failure to reflect versioning changes. Given this situation, a distribution could either downgrade their packages (by adding "epoch" markers, 7.1.0 => 1:1.4.3), or by tagging on Hyfetch changes (either as 7.1.0+hyfetch1.4.3 or 7.1.0+git20221113). However, by doing so, distributions risk either (1) failing to reflect Neofetch versioning changes (users install Neofetch 7.1.0+fetch1.4.3 but the scripts report version 7.3.3, or (2) failing to reflect Hyfetch's de facto upstream status (by not following Hyfetch's versioning convention).

The second point is especially concerning, as distributions may use update checkers to track upstream package versioning. Fedora's Anitya or AOSC OS' aosc-findupdate will not be able to effectively track and apply update information on their packages - as no exact versioning is reflected on Neofetch.

In short, it's unworkable for us distribution packagers (we might miss updates) and it has the potential to confuse users (see point 2 above, complicated versioning markers and inconsistent version reporting).

What do you propose?

From my standpoint (as an AOSC OS maintainer), I urge changes to your release strategies. As you are the de facto upstream, we strongly suggest that you make your project workable for distribution packagers, especially now that Neofetch has been packaged by so many distributions. I propose the following methods (that I would consider ideal or at least workable), for your reference:

1. Restore Neofetch as a dedicated project, and incorporate its code as a Git submodule in this repository. This way, we have a consistent location to track Neofetch changes and it reflects the nature of this project much better.
2. Tag Neofetch with a prefix. If option 1 would not work under any circumstances, please consider tagging Neofetch versions like neofetch-7.3.3, so that distributions can still have a clear idea of what is going on here.
3. At the very least, reflect Neofetch changes in commit messages. But truthfully, I simply don't see why either option 1 or 2 wouldn't work.

I can, however, see an argument that Hyfetch is not the upstream or the fact that @dylanaraps might one day pick up Neofetch again. But hey, they have been inactive for close to a year now. A year is a long time for bug fixes to sit undiscovered by distributions. @dylanaraps also has all the power to apply changes made here in this repository if and when they decide to reboot the project.

[hykilpikonna]

Sorry for the inconvenience. I just followed your second suggestion and created retroactive neofetch tags to correspond with neofetch versions if that helps. I also attached neofetch versions in GitHub release notes.

I also considered the first suggestion, but even though retroactively separating out neofetch and hyfetch commits and making two separate repos is possible, it requires a lot of work and also might make the existing commit hashes invalid. However, you can view only neofetch-related commits using git log 'neofetch'

Also, even though this is a maintained fork of neofetch, @dylanaraps and I have a somewhat different vision for the project. (e.g. you can see it in dylanaraps/neofetch#1890, dylanaraps/neofetch#1971, dylanaraps/neofetch#1706, dylanaraps/neofetch#1631). Dylan wants to keep the codebase clean, reluctant to accept distros like Twister OS, Virtuozzo, and DietPi that need special methods to identify. On the other hand, my fork is inclusive and accepts all public distros. Also, Dylan enforces a strict approach in accepting contributions, often expecting the contributors to thoroughly understand the codebase and fix any issues he finds (e.g. dylanaraps/neofetch#1588), while I use a collaborative approach where I often fix issues for the contributors after merging. So, even if Dylan decided to continue maintaining neofetch, he might not be happy with some of the changes I made. I don't know if my maintained version of neofetch in hyfetch can entirely replace neofetch--although unlikely, there still exists a possibility that Dylan will pick up neofetch someday and start new releases from 7.1.1.

I can try to contact Dylan for his opinion, I'll follow up on this thread if there are any updates.

To avoid potential conflict, I renamed my updated neofetch script to neowofetch in the pip and npm install scripts, and I think it would be safer to package it as a separate package or have some way to identify my fork in the versioning until we have an official message.

[FabioLolix]

my fork is inclusive and accepts all public distros

even at least 2 private ones or without any release to be honest

[Un1q32]

Dylan wants to keep the codebase clean, reluctant to accept distros like Twister OS, Virtuozzo, and DietPi that need special methods to identify. On the other hand, my fork is inclusive and accepts all public distros. Also, Dylan enforces a strict approach in accepting contributions, often expecting the contributors to thoroughly understand the codebase and fix any issues he finds

I believe the reason for this is they want neofetch/pfetch to be learning resources for people learning bash/sh first, and actual system information tools second.