View Issue Details

IDProjectCategoryView StatusLast Update
0005525SUMoBugpublic2019-07-31 15:49
Reporterwolf Assigned ToKyle_Katarn  
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionopen 
Product Version5.9.2 
Target Version5.10.xFixed in Version 
Summary0005525: SUMo detection of LyX
DescriptionI've installed the open source distribution LyX which includes Strawberry Perl, Python and ImageMagick as components, formerly also a TeX distribution now requiring one preinstalled. SUMo detects the components of LyX although NOT LyX itself as Lyx has its version information not in a standard Windows version info format except for its uninstaller but otherwise in folder name.

Please fix SUMo detection and reporting of LyX!
Steps To ReproduceInstall LyX (source: https://www.lyx.org/ ),
run SUMo (deep) scan,
then SUMo check,
and look for LyX in the resulting SUMo report.
Additional InformationWhile it might be conveniant that SUMo filters out installers and uninstallers in its reporting, it is a bug to filter them out for scanning resp. detection and checking. As shown in the sample of LyX, product version info may be complete in the Windows installer while the other binaries are not designed as much platform specific. (Linux has still not learned to show the binary version info as opposed to Unix. Hence version info is handled by the installers resp. package management handlers not needing that information in the binary. Nevertheless it's common practice to have the main program also report it in its command line interface.)

Find attached the screenshots for properties and version details of Windows LyX binary and uninstaller.

While LyX Windows program folder name carries the product version info, the LyX Windows uninstaller carries also the patch level.
TagsNo tags attached.

Relationships

related to 0005524 acknowledgedKyle_Katarn Strawberry Perl product name consolidation 

Activities

wolf

2019-06-02 15:17

reporter  

lyx.prop.20190602.png (26,909 bytes)
lyx.prop.20190602.png (26,909 bytes)
lyx.detail.20190602.png (18,634 bytes)
lyx.detail.20190602.png (18,634 bytes)

wolf

2019-06-02 20:19

reporter   ~0003432

According to LyX, version info has been introduced into its Windows binaries back in 2007. I also opened a bug report in LyX so that they reenter it in future updates in its binaries. Their bug tracking system provides also automatic schedule forecasts. Although they claim the next minor release immediately pending, their traching system shows otherwise with 14 issues pending (out of 92) before release.

Kyle_Katarn

2019-06-02 20:32

administrator   ~0003433

ok, thanks !

wolf

2019-06-27 01:01

reporter   ~0003511

When updating LyX, SUMo still doesn't detect LyX. This updated version of LyX has file version info.

The preceeding versions of LyX had version info at product level, not at file level. So the version info was already present in windows MSI database of installed products though not included in its binary files version info. With the update, it is now also in LyX.exe. And SUMo still doesn't report it.

When I asked SUMo instead to rescan and then recheck, it reports now this file version info.

Shall I open two new bug reports?
One for this case of updates and one for ignorance of version info at product level in windows MSI database, both considered lower priority than hierarchical grouping?

Kyle_Katarn

2019-06-27 22:20

administrator   ~0003516

The file mentionned above is automatically discarded as it is an installer/uninstaller. As per design.
You need to have the main exe with file version info.

wolf

2019-06-28 18:37

reporter   ~0003518

No, I disagree. The first two paragraphs of note https://www.kcsoftwares.com/bugs/view.php?id=5525#c3511 are referring to LyX.exe. I consider this the main program, no installer nor uninstaller. If you install it, you don't find it in the in the product root program folder but instead in its "bin" sub folder while finding the uninstaller ind the product root program folder.

And in my initial description, the first two screen shots refer to the file of same name in its non-updated version. The following two screen shots may explain why the version is reported in MSI windows database while not found in the file version info, for the non-updated version. But again, as written in note https://www.kcsoftwares.com/bugs/view.php?id=5525#c3511, you'll find now the version as well in MSI windows database as in file version info of the main program (although still not in its assisting DLLs) starting with the updated version of this month.

The problem with SUMo is that when it (silently) discards reporting detected programs with no version info at file level at the time of scanning, it does not reevaluate that list of those discarded programs after an update of an already installed program. There is an option in SUMo if scanning should operate in standard mode or in deeper advanced mode. As long as no additional option is provided between standard checking and advanced checking, it sounds fine to keep that limitation for standard checking mode while reconsidering the list of detected programs discarded of reporting due to missing version info, not due to configured exclusion list nor due to configured reporting drop lists. Again, I consider these limitations as low priority bugs as a working work around is rescanning by SUMo.

With the additional analysis of this note, it provides some clue for the observation between product level and file level by Windows. I recommend to create those two low priority issues proposed in note https://www.kcsoftwares.com/bugs/view.php?id=5525#c3511 to be scheduled at short term or long term not before implementation of hierarchical reporting while fixing two aspects of design and implementation with this issue. These one to two aspects are handling the list of detected programs with no version info at file level and the consideration to distinguish between standard mode checking versus advanced mode checking, considering deep advanced scanning as implicating advanced mode checking too as long as no seperate configuration option is provided. You should not drop the list created during scanning of programs detected with no version info found at file level. In standard checking mode, I consider it fine to continue ignoring that list while in advanced checking mode this list should be processed too as file version may have been added since the last scan and last check.

How does SUMo handle the situation that while in 2007 SUMo may have detected LyX, LyX lost its version info at file level in Windows some unknown time later. As long as no additional scan would shift LyX off the reported list to the list of detected and discarded programs with lost file version info, what would be the behaviour of SUMo (in reporting as well as in checking)?

wolf

2019-06-28 18:38

reporter   ~0003519

Forgot to attach the screen shots of updated properties of updated LyX.

wolf

2019-06-28 18:39

reporter  

lyx.detail.20190628.png (25,447 bytes)
lyx.detail.20190628.png (25,447 bytes)

wolf

2019-06-28 18:39

reporter   ~0003520

Forgot to attach the screen shot of updated properties of updated LyX.

Kyle_Katarn

2019-07-01 16:42

administrator   ~0003530

Looks like it has all required info to get recognized by SUMo now. Does drag'n'drop of this exe file actually adds it correctly into SUMo ?

wolf

2019-07-01 18:42

reporter   ~0003531

What do you mean by drag'n'drop?
Do you refer to the additional folders section in settings?

Then it's not what I want. And I don't expect a different behaviour then scan operation which works with the updated LyX.

The problem is wrong handling of detected tools without detected file version info while product version info is present. You ignore the product version info. And you remove those files in the postprocessing of the scan operation instead of moving them to a seperate list. And you should check this additional list in deep check mode too while you may continue ignoring it in standard check mode. But you may not drop this ignore list as the user may any time toggle its configuration of standard to advanced. And this additional list becomes relevant not with installing new programs but with updating already installed programs. And if you don't have this list, you may not check it, even not in advanced check mode.

So for scheduling a fix, you may take into account that performing a scan action is a valid work around.

And the initial lack of detection is due to ignoring version info at product level while not finding version info at file level. This has been (partially) fixed on the concerned product Lyx side.

And before better handling product version info, you should implement hierarchical grouping. Otherwise users may get overwhelmed with information and don't have sufficient means addressing and grouping these information sets.

So while I consider the missing product version info reporting addressed as minor aspect in this issue, I prefer to focus on the ignore list and be happy when this issue gets resolved with adequate ignore list handling, not needing to wait for product version handling.

wolf

2019-07-01 18:49

reporter   ~0003532

A temporary solution to product version handling is to proceed differently with postprocessing of the scan action. You may have to keep the installer and uninstaller infos for some while instead of ignoring them all together. If the scan detects the corresponding programs, you may proceed to drop and ignore those installers and uninstallers. If the corresponding products don't carry file version info you've to decide how to process product version info and how to associate it to the corresponding member of the ignore list (of detected programs with missing file version info). It's fine to limit such a temporary solution to advanced scanning. And this is not instead of implementing better ignore list handling but in addition.

Kyle_Katarn

2019-07-01 19:00

administrator   ~0003533

In fact, my question was not a definitive workaround but a validation of a possible step towards solution.
If you drag'n'drop Lyx.exe onto SUMo does it get correctly listed ?

wolf

2019-07-01 19:31

reporter   ~0003534

I didn't get an answer to my question in note https://www.kcsoftwares.com/bugs/view.php?id=5525#c3531 what you mean by drag'n'drop.

Nevertheless I can confirm that a new SUMo scan action gets LyX properly detected. I don't know if this is equivalent to your proceeding and question. It seems so to me.

Kyle_Katarn

2019-07-01 20:24

administrator   ~0003535

OK that's perfect! Isn't it the expected behavior ?

wolf

2019-07-02 12:24

reporter   ~0003536

Yes and no.

For initial detection via scan, it works now also for LyX. In this sense, it's a yes.

But with previous version installed, SUMo scan and check ignore product version of LyX which was present. In SUMo scan post processing it has put that former version of LyX itself (not its components) onto SUMo discard list as it didn't have file version info. When updating LyX with fixed file version info, SUMo check keeps the updated LyX on SUMo discard list instead of moving it to SUMo report list! In that sense, it's a no. This is not expected behaviour. Do you want a new issue or do your prefer fixing it with this issue?

wolf

2019-07-02 12:28

reporter   ~0003537

And I forgot to mention that SUMo scan and check ignore the product version in case no file version is found, is also not expected behaviour. That's what I reported in note https://www.kcsoftwares.com/bugs/view.php?id=5525#c3532 . Do you want a new issue for this or do you prefer fixing this also with this current issue?

Kyle_Katarn

2019-07-30 21:21

administrator   ~0003652

I'd prefer to look at the remaining problem here but i actually don't underdand what your problem statement is.
May I have screenshot showing what's wrong ?

wolf

2019-07-31 15:49

reporter   ~0003653

No, I can't provide a screenshot of the old situation. I can repeat the two aspects remaining. Indirectly, it has to do with missing specification what SUMo considers a version to report with several options available and implications on design and implementation. The original observation was that SUMo didn't report the product version of LyX although reporting the product version of some components of LyX and although product version of LyX itself was known and reported by Windows! So of the initial situation, there remains one aspect, and with a change in LyX, this revealed a second aspect:

1) SUMo scan action initially detected LyX but did report so ONLY in its logfile, not in its final report. It did so because the main executable and its main shared libraries didn't have file versions included (hence discarded and removed of the draft report list because of missing file version) although product version existed and was reported by Windows (i.e. control panel -> programs -> programs and features). Windows takes and knows the product version of installer and uninstaller which seemingly was ignored by SUMo.

Probably the best solution will require some redesign and refactoring of SUMo scan action. I don't know if the initial draft report list established by SUMo scan action does include all binaries including libraries found in the selected system directories and additional folder directory trees. According to its size of more than 24100 entries on my notebook, I guess yes for the binaries and no for the libraries. Then it removes selected entries of this draft report list, eliminating duplicates, installers and other special case binaries for special suppressing or filtering, then it removes those entries with empty file version in binary version field section. In such a redesign, it would not only remove those entries of the draft report list but keep them unto the end of the scan action or even longer, eventually depending on SUMo configuration. For SUMo standard scan mode, it might be ok to keep functionality unchanged. But for deep scanning mode, it seems ok not to report these sublists in the final SUMo report list, but it doesn't seem ok to delete them. SUMo should keep in deep scanning mode instead the lists of installers resp. uninstallers detected and the executables with incomplete file version info section as they're still useful and may get reported by additional advanced SUMo menu entries. There is a link between the installers resp. uninstallers and the executables installed. This relation matters for the observed case reported in this issue when the executable doesn't have complete file version section filled. In that case, SUMo may get and report the product version by taking that information of the corresponding installer resp. uninstaller. The list of executables without file versions is relevant not only for addressing this case but also for the 2nd remaining aspect of this issue.

2) Usually, a SUMo scan action is recommended after some products have been installed or uninstalled by system administrator or user. For the case of updates of the operating systems or the installed programs, a SUMo scan action seems not necessary, instead recommending a SUMo check action. And as the fix in LyX file version section has shown, SUMo ignores this updated file version section as it does not check the list of detected programs with incomplete file version section. When a new SUMo check action is initiated by SUMo user, SUMo cannot know if an incomplete file version section still is incomplete or has been updated by a program update since the last SUMo check action! So it's a bug that SUMo check action doesn't process again the list of detected programs suppressed of reporting due to incomplete file version section at least for the deep scan (and checking/reporting) operation mode of SUMo.

So probably the best solution is to continue processing of check action not only on the existing SUMo report list but to proceed with the list of previously detected programs with incomplete file version section. If the check action on these programs suppressed previously for reporting reveals an update of the file version section, these updated programs should no longer be suppressed but instead moved of this suppressed list to the SUMo report list with the results of the current check action.

So are these remaining aspects now clear?

Issue History

Date Modified Username Field Change
2019-06-02 15:17 wolf New Issue
2019-06-02 15:17 wolf File Added: lyx.prop.20190602.png
2019-06-02 15:17 wolf File Added: lyx.detail.20190602.png
2019-06-02 15:17 wolf File Added: lyx.uninst.prop.20190602.png
2019-06-02 15:17 wolf File Added: lyx.uninst.detail.20190602.png
2019-06-02 15:17 wolf Issue generated from: 0005524
2019-06-02 15:17 wolf Relationship added related to 0005524
2019-06-02 19:50 Kyle_Katarn Assigned To => Kyle_Katarn
2019-06-02 19:50 Kyle_Katarn Status new => acknowledged
2019-06-02 19:50 Kyle_Katarn Target Version => 5.10.x
2019-06-02 20:19 wolf Note Added: 0003432
2019-06-02 20:32 Kyle_Katarn Note Added: 0003433
2019-06-27 01:01 wolf Note Added: 0003511
2019-06-27 22:20 Kyle_Katarn Note Added: 0003516
2019-06-27 22:20 Kyle_Katarn Status acknowledged => feedback
2019-06-28 18:37 wolf Note Added: 0003518
2019-06-28 18:38 wolf Note Added: 0003519
2019-06-28 18:39 wolf File Added: lyx.detail.20190628.png
2019-06-28 18:39 wolf Note Added: 0003520
2019-07-01 16:42 Kyle_Katarn Note Added: 0003530
2019-07-01 18:42 wolf Note Added: 0003531
2019-07-01 18:49 wolf Note Added: 0003532
2019-07-01 19:00 Kyle_Katarn Note Added: 0003533
2019-07-01 19:31 wolf Note Added: 0003534
2019-07-01 20:24 Kyle_Katarn Note Added: 0003535
2019-07-02 12:24 wolf Note Added: 0003536
2019-07-02 12:28 wolf Note Added: 0003537
2019-07-30 21:21 Kyle_Katarn Note Added: 0003652
2019-07-31 15:49 wolf Note Added: 0003653