[Gchemutils-main] A few hints by the Debian quality tools

[Daniel Leidert]

Hi Jean,

There are a few hints output by lintian, the package quality checker of
Debian GNU/Linux. Maybe you'd consider to fix these issues:

> I: gchempaint: desktop-entry-lacks-keywords-entry 
> usr/share/applications/gchempaint-0.14.desktop
> N: 
> N:    This .desktop file does either not contain a "Keywords" entry or it does
> N:    not contain any keywords not already present in the "Name" or
> N:    "GenericName" entries.
> N:    
> N:    .desktop files are organized in key/value pairs (similar to .ini files).
> N:    "Keywords" is the name of the entry/key in the .desktop file containing
> N:    keywords relevant for this .desktop file.
> N:    
> N:    The desktop-file-validate tool in the desktop-file-utils package is
> N:    useful for checking the syntax of desktop entries.
> N:    
> N:    Refer to
> N:    http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html,
> N:    http://bugs.debian.org/693918, and
> N:    https://wiki.gnome.org/Initiatives/GnomeGoals/DesktopFileKeywords for
> N:    details.
[..]

This goes for all .desktop files.

> W: gcu-bin: desktop-mime-but-no-exec-code 
> usr/share/applications/gspectrum-0.14.desktop
> N: 
> N:    The desktop entry lists support for at least one mime type, but does not
> N:    provide codes like %f, %F, %u or %U for the Exec key.
> N:    
> N:    If the application can indeed handle files of the listed mime types, it
> N:    should specify a way to pass the filenames as parameters.

IIRC gspectrum indeed does not open a file given on the command line. Is
this correct? Maybe then you should add a file handler? If I'm wrong,
then the Exec line needs a minor fix.

> X: libgcu0: shlib-calls-exit usr/lib/libgcrystal-0.14.so.0.14.10
> N: 
> N:    The listed shared library calls the C library exit() or _exit()
> N:    functions.
> N:    
> N:    In the case of an error, the library should instead return an
> N:    appropriate error code to the calling program which can then determine
> N:    how to handle the error, including performing any required clean-up.
> N:    
> N:    In most cases, removing the call should be discussed with upstream,
> N:    particularly as it may produce an ABI change.
> N:    
[..]
> X: libgcu0: shlib-calls-exit usr/lib/libgcugtk-0.14.so.0.14.10

I'd consider the hint correct. A library should not exit() and leave
this to the program. What do you think?

Regards, Daniel