Comment # 17 on bug 4041 from Dominik 'Rathann' Mierzejewski

(In reply to Nicolas Chauvet from comment #16)
[...]
> Then maybe you can drop the i486 package and only package the x86_64 as
> ExclusiveArch: x86_64.
> 
> If any end-user would need the 32bit support, then they can contribute the
> packaging change.
> 
> Anyway, both options are possible.

I agree it probably doesn't make sense to ship the 32bit x86 version unless
there's demand for it.

> Please try to use the %global defines on the top of the spec file (they have
> been added twice).
> 
> libMendeley.so is packaged in a -devel sub-package, but there is no header.
> Are you sure this symlink to the library isn't used at runtime ?

There's no need for libMendeley.so at all. Only the versioned file and symlink
are needed.

> libPDFNetC is a library from another project. If you are using the pre-built
> version from Mendeley, it will conflicts if both packages are installed.
> https://github.com/PDFTron/PDFNetWrappers

That contains only wrappers for PHP, Python and Ruby. The PDFNetC is still
closed source: https://www.pdftron.com/pdfnet/downloads.html . The latest
version (6.7.1) still bundles stuff like openssl-1.0.1c, libpng-1.6.12 and
zlib-1.2.7.

I actually tried dropping the latest upstream version in place of the one
bundled with MendeleyDesktop and it crashes on some PDFs I tried to import.

> Instead you need to either:
> - Package libPDFNetC (in fedora) and use the version built from source.

Impossible, sadly.

> - Use a dedicated path, not registered to the system linker, so Mendeley can
> find it's libraries. (and add something like /usr/lib64/Mendeley to
> LD_LIBRARY_PATH).

That'd be one option, as long as it's not added to the global LD_LIBRARY_PATH
if you want to go all the way. However, in all likelihood, nothing else will
ship libPDFNetC, so I'm not sure it's worth the trouble.

You can find my latest spec+patch here:
https://rathann.fedorapeople.org/nosrc/mendeleydesktop/