That would solve only one half of the problem. The other half is "I have this app installed and I can't remove it!".
Even worse, some users even get the idea that F-Droid somehow installed this app that they know nothing about, thinking that F-Droid is installing stuff without their permission.
AppDetails should just hide the delete options for system apps. I think if there is a system app with a signing key matching what's in f-droid, then it should show up normally and be available for upgrade. That's how it works in Google Play, for what its worth.
We also need this for swap. swap needs to know whether its a system app with an update
installed, otherwise it should ignore it. That will then filter out things like the system components that are not apps really. @pserwylo I was looking into how to store the data for this, it looks like it'll have to involve the database somehow, since SelectAppsView and AppDetails are both driven by the database. It would be a good thing to discuss at the next scrum, I couldn't quite figure it out.
This is the kind of stuff that we really need in place before we do the UI overhaul.
I've just bumped into this courtesy of the authors publishing a non-system upgrade to the (currently) system App "My Contacts" under FPOOS. The error message I got was
Error uninstalling %sFailed to uninstall due to an unknown errorOK
Could I make a plea that you don't simply "not show" the uninstall button? Without explanation that's going to be just as frustrating and confusing as the above message, particularly in conjunction with the "Signing key has changed — uninstall the original before installing this update" message I got for My Contacts (which is migrating from a system app in the current version of FPOOS to non-system in the next version if I understand correctly). If F-Droid tells users to uninstall an app while hiding its uninstall button, those users are going to be mightily confused.
I'd suggest either replacing the button with a "System apps cannot be uninstalled" message, or leaving the button there and displaying a meaningful message if the user tries to use it. Removing or greying-out the button without explanation will just result in confused users posting "Where's the uninstall button" messages to forums and support pages.
In the case of overlap with #122 (i.e. an independent update appears for a system app), perhaps a pointer to the "ignore updates" option could be added, if that gets implemented. I'm not sure how safe that is though: can a system app be updated by its publisher? If so, would an "ignore updates" button ignore both independent updates and those of the original publisher? Sounds as if the plan detailed on #122 to ignore updates with different signing keys will solve that wrinkle though.