--- Comment #17 from Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net>
(In reply to Nicolas Chauvet from comment #16)
Then maybe you can drop the i486 package and only package the x86_64
If any end-user would need the 32bit support, then they can contribute the
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
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
libPDFNetC is a library from another project. If you are using the
version from Mendeley, it will conflicts if both packages are installed.
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
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.
- Use a dedicated path, not registered to the system linker, so
find it's libraries. (and add something like /usr/lib64/Mendeley to
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:
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.