Remove legacy apps with ports

[danirabbit]

Problem

There are some legacy apps which have been ported, but using a new RDNN. There are also some that were abandoned, but forked and submitted under new branding.

It would be helpful to not show those under the legacy apps section to more accurately reflect what's missing from the Flatpak store

Proposal

@cassidyjames recommended that we might check for a tag somewhere where developers can say their app provides/supersedes some other RDNN

We might also want some kind of ignore list

Prior Art (Optional)

No response

[danirabbit]

I have no idea why, for example, Harvey shows up under legacy apps even though I've ported it

[RMcNeely]

I can look into this if you know of any more apps like Harvey that are dual listed or superceded with new RDNN's.

[ChildishGiant]

I think automating this one-time task would be over-complicating it. I'd happily go through and make a list of ones to skip displaying/forward to the new version. Maybe adding a checkbox for "my app is a port of a Hera app" on the GitHub submission form?

[aral]

@danrabbit I believe it happens if you have it installed via a different Flatpak remote (even a local one). I got the same thing with Comet after seeing it appear on the AppCenter.

The way I was able to get it to show up properly was to uninstall all other Flatpak versions of it (the development build and the sideloaded one from the Comet web site) and restart AppCenter.

[cassidyjames]

@danrabbit I filed your issue with Harvey at https://github.com/danrabbit/harvey/issues/48, but also fixed/worked around it in ca63389cc6406baad88823610ec80779a88ef896. It doesn't fix the case of e.g. Spice-up where the RDNN actually changed (in that case a dash to underscore), or if the RDNN changed completely.

[cassidyjames]

The specific metainfo we should be asking developers to include:

<provides>
  <id>com.example.old.rdnn</id>
</provides>

(source)

Then we can check that tag and create redirects.