View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002373||SUMo||New Feature||public||2013-12-06 10:28||2019-08-26 14:05|
|Target Version||Short term||Fixed in Version|
|Summary||0002373: Reporting when multiple versions of same product installed|
|Description|| Some applications might -- during their update process to newer versions -- leave older modules behind (sometimes, even the main module, as the newer one has a different name).|
Regretfully, while the most up-to-date version might be installed, SUMO continues to "nag" that updates are available, because it also sees some of the previous modules on the machine.
It would be nice to apply the same "clean-up" methodology that Secunia's PSI (2.x and possibly 3.x) does, according to which an update suggestion is offered only when no copy of the most up-to-date version is found on the machine being scanned (not only if older modules are found).
To deal with the fact in some cases it is beneficial to report on all versions installed on the machine, maybe an option could be added, to let SUMO "know" how to behave (similar to the "Do not report Betas)
|Tags||No tags attached.|
||I observe the same behaviour. These are hence currently false positives and hence confusing. But ignoring them is not a good idea as they may need other action (not update but cleanup by other tools). So for standard use case, suppressing this kind of info leads to less confusion. But creating such a report of orphaned predecessors shall remain possible. Hence I prefer a configuration option with ignoring being the standard behavior and reporting intended for advanced users.|
||What about "delete" function ? Why wouldn't you use "Ignore" ?|
What do you mean by delete function?
Do you mean to delete files as a method for cleanup?
Often this is a bad idea as those components are often necessary for a certain feature of the installed package. And SUMO does not yet report directly the relationship of installed application and installed component. So deleting would remove a subset of features of the installed package. And if the component is essential for basic features, the application might be rendered unusable.
And most installers on my system don't provide a repair mode. Even if the installer software would be able to support such a mode, many software publishers don't make use of this feature and operation mode.
I don't like ignore in SUMO as I want to know the details, relationships, existence and many more meta data. And as far as I understood, ignore is currently a very coarse grained configuration option with further tuning options in the development backlog.
And it makes a difference if a component is not updated although should have been by performing the update installation, i.e. because it was in use on that time and the installer didn't require to stop the application first, or because it is no longer needed. SUMO does not provide corresponding information. And it seems to me that often an application may work properly with several predecessor versions of components. I can imagine that some software publishers don't know the installer software and features not well enough and resulting in a different configuration set if updating or if installing freshly, not by design but by lack of knowledge. For such cases data backup, uninstall and reinstall can be a remediation resp. cleanup method, not delete nore ignore as action is needed.
||"Delete" removes item from the list but do NOT delete any file on the user's system.|
I don't like such a SUMo delete function. It only hides existing system administration issues existing. So there are use cases where I'm not interested to see some of these instances reported while there are others where I prefer seeing them and get reported.
And unclean updates are not the only reason for multiple reporting, nor another another reported SUMo bug for products included in PortableApps framework, regardless if the same product is also installed classically on the local computer. Another use case where tools are reported multiple times in multiple versions has to do with portable products too, and has nothing to do with that other SUMo bug. As portable products don't know nor care which tools are already installed classically nor if required tools are also provided by other portable products, they supply it, similar to side-by-side installation of Windows. As a consequence, there are some tools installed various times locally as components to various distinct portable products. So while these portable products may be unique, this often doesn't apply to their components. And SUMo tells me which portable product has the same tool component installed in which version. These portable product publishers don't update these components as regularly as they update their main product. And different portable product publishers have different update cycles. In consequence, as I have also larger portable product frameworks installed, I end up with some component tools reported many times in many different versions. Depending on the kind of portable product software architecture, I may manually replace the supplied component with an updated component without interacting with the portable product publisher. And SUMo tells me where to look and to act. That's why I don't want to use the SUMo delete function. And that's why a uniform SUMo ignore function isn't appropriate neither. So I need a switchable SUMo configuration option when to show those multiple instances and when to ignore them.
The original reporter doesn't seem to want to do the system administration tasks for clean up. So for him the SUMo delete or ignore functions may be approriate for those outdated instances left by unclean updates. I'm not sure if the original reporter already knows these SUMo functions, their difference and which means and options exist to use them. I use the SUMo ignore function to some extent. And I've read that this function has more options then yet shown to me. So I guess that it's an inconsistent UI of SUMo too, needing to add the whole set of options to any entry point of that function. I usually use the context menu and find no options there (temporarily, how long, permanently, dependent or independant of changes in available updates of update of outdated product).
I prefer a cleaner system. But I don't have the time nor interest to do that clean up every time a request a SUMo check action. When I've the time though, then I need those informations of outdated products or tools.
I remember having read the claim that SUMo reports the newest locally found version when looking up on SUMo server with the user flag (or not using a user flag at all on other times). But that's not true neither. I don't know yet how this user flag should be set when multiple versions detected locally. I consider not using it a bad idea. Using it for the highest version detected locally seems to me often the best idea. That's the standard case when looking for needed tool updates. Sometimes it seems to me better to use the lowest version detected locally. That's better when wanting to do some system administration clean up. But why not provide a SUMo configuration option for determining this kind of flagging and reporting?
Find attached some screenshots with multiple instances of the tool ImageMagick which is also component to some other products. And SUMo didn't report the current version correctly as no SUMo user seems to have already updated to the most recent release yet. That's no bug of SUMo and gets fixed automatically when sufficient users update to the most recent release. The screenshots shall show instead the strange flagging of the SUMo user flag on SUMo server instead. So I guess the algorithm of SUMo for reporting user flag needs some update too.
||I confirm that "user" tag displayed may be incorrect if your SUMo lists multiple different versions of the same product / company item.|
|2013-12-06 10:28||trattner||New Issue|
|2013-12-08 20:44||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2013-12-08 20:44||Kyle_Katarn||Status||new => acknowledged|
|2019-04-15 22:40||wolf||Note Added: 0003218|
|2019-04-17 21:43||Kyle_Katarn||Note Added: 0003227|
|2019-04-21 17:51||wolf||Note Added: 0003241|
|2019-04-21 22:51||Kyle_Katarn||Note Added: 0003244|
|2019-07-21 18:01||wolf||Note Added: 0003592|
|2019-07-21 18:18||wolf||Note Added: 0003593|
|2019-07-24 21:50||Kyle_Katarn||Note Added: 0003600|
|2019-08-26 14:04||Kyle_Katarn||Relationship added||related to 0005655|
|2019-08-26 14:05||Kyle_Katarn||Target Version||=> Short term|