FIX - old hardinfo merged to new community version hardinfo2

[hwspeedy]

As agreed - added rule to merge hardinfo into hardinfo2.

[AMDmi3]

Are you sure it should be hardinfo2 and not hardinfo? I tend to treat numeric suffixes in cases where fooN+1 supercedes fooN or foo, or where's there was no fooN or foo [in the wild] to begin with (like for instance with mandelbulber2) as technical and insignificant and merge into mere foo. It also doesn't feel correct to merge legacy hardinfo into hardinfo2 which it's not.

[hwspeedy]

The new community project name is hardinfo2 which is also the package name.

The old maintainer would not give the domain as it was used for personal stuff - has given so much trouble, but that's how it is.

All old versions before 2.0.0 are a mess - most are some just taken from unstable git as no release was made and they had lots of bugs in Debian and a lot more not found/reported. The project lost both the maintainers interest and the benchmark server without backup. See history here: https://hardinfo2.org/history

The old hardinfo repo is removed soon - https://github.com/lpereira/hardinfo/blob/master/README.md

hardinfo 0.5.1+Mess -> hardinfo2 2.1.11 - https://github.com/hardinfo2/hardinfo2/releases/tag/release-2.1.11

I just want to could see all repos having the updated version 2.0.0+ along with the once I expect it to get backported to - We support ~10 years back porting.

hardinfo needs a clean out with updates, but not EOL distro is not the same as updateable and if they cannot be updated, they have no interest in the maintenance eye.

That's why a minimum version of package in order for it to show in the badge is important for maintaining the merged package name hardinfo2.

Does that explain the situation?

[hwspeedy]

I decided to make my own filter for this corner case.