I fixed in Cauldron, but this is a valid bug in Mageia 2.

Status: NEW => ASSIGNED
CC: (none) => malo
Hardware: i586 => All
Version: Cauldron => 2
Assignee: bugsquad => malo
Source RPM: (none) => mupdf-0.9-3.mga2.i586

Thanks for the quick fix. 

Works for me now in Cauldron: mupdf-1.0-1.mga3
If it continues to be important for Mageia 2, please clone this bug.

Status: ASSIGNED => RESOLVED
Version: 2 => Cauldron
Resolution: (none) => WORKSFORME

No need to clone it. we can just use the same bug report since it's the same bug. That's why I switched the version to Mageia 2. Please leave it like this. Other people will close it.

Status: RESOLVED => REOPENED
Version: Cauldron => 2
Resolution: WORKSFORME => (none)

Dear QA, could you test this package in updates_testing of Mageia 2? Thanks

Advisory:
========================

Updated mupdf package adds an explicit conflict with poppler: installation was failing because of a file conflict.

========================
Updated packages in core/updates_testing:
mupdf-0.9-3.1.mga2.src.rpm
========================

Status: REOPENED => ASSIGNED
Assignee: malo => qa-bugs

IMHO better solution would be renaming the binaries coming from mupdf so pkgs could co-exist.

CC: (none) => jani.valimaa

(In reply to comment #5)
> IMHO better solution would be renaming the binaries coming from mupdf so pkgs
> could co-exist.

You could use mu prefix in binaries starting with pdf like it's done in mupdf 1.0.

(In reply to comment #6)
> (In reply to comment #5)
> > IMHO better solution would be renaming the binaries coming from mupdf so pkgs
> > could co-exist.
> 
> You could use mu prefix in binaries starting with pdf like it's done in mupdf
> 1.0.

Is that known to upstream development? I would not like a mageia only patch. 
There are some bugs open for pdfinfo especially, look at http://bugs.ghostscript.com/

Another idea can be to split the mupdf package and separate pdfinfo of mupdf into a new package itself with a conflict to poppler. So, it's easier to handle for the dependency resolver.

Upstream mupdf 1.0 ships binaries starting with mupdf, it's not patched by Mageia.

See: http://git.ghostscript.com/?p=mupdf.git;a=commit;h=78e29456b051f41073d706ac7d3eb76bfa08b0ab

Fedora renamed their pdfinfo to pdfinfo-mudpf.

See:
http://pkgs.fedoraproject.org/gitweb/?p=mupdf.git;a=blob;f=mupdf.spec;h=bf5701e88c29677691dcbfaa262db7ec2f03bf57;hb=a8bcd89b8cb936de7f0950fe00849abfa60edf83

Yes, I can rename the binaries as in version 1.0. I should have thought about that. I'll do it.

Dear QA, could you test this package in updates_testing of Mageia 2? Thanks

Advisory:
========================

Updated mupdf package uses renamed executables to avoid a file conflict with poppler.

========================
Updated packages in core/updates_testing:
mupdf-0.9-3.2.mga2.src.rpm
========================

Testing on MGA2, i586.

CC: (none) => wassi

Testing complete on MGA2, i586.

I could reproduce the problem, the update fixes it:

Installing mupdf initally (without Core Updates Testing enabled) failed because of a file conflict with package poppler.

However, installing the package from Core Updates Testing worked without any problem, poppler and mupdf now peacefully coexist on my system and both work (I threw some random PDFs at both Okular (which uses poppler) as well as mupdf (it can be easily invoked from the command line using "mupdf sample.pdf")).

SRPM: mupdf-0.9-3.2.mga2.src.rpm

Whiteboard: (none) => MGA2-32-OK

Noticed one more thing, we need to rename man pages also.

Good catch. I'll provide a mupdf-0.9-3.3.mga2 ...

Dear QA, once again, could you test this package in updates_testing of Mageia 2? Thanks

Advisory:
========================

Updated mupdf package uses renamed executables to avoid a file conflict with
poppler.

========================
Updated packages in core/updates_testing:
mupdf-0.9-3.2.mga2.src.rpm
========================

Whiteboard: MGA2-32-OK => (none)

I mean mupdf-0.9-3.3.mga2.src.rpm of course :)

Testing x86_64

Urpmq shows it is a leaf package so nothing else should need rebuilding for the renamed executables.

$ urpmq --whatrequires mupdf
lib64mupdf-devel
libmupdf-devel
mupdf

Checking for conflicts..

Before
------
$ urpmf --media Release mupdf lib64mupdf-devel | awk -F":" '{print $2}' | sort -u > mupdf.txt
$ urpmf poppler | awk -F":" '{print $2}' | sort -u > poppler.txt
$ comm -12 mupdf.txt poppler.txt 
/usr/bin/pdfinfo

After
-----
$ urpmf --media Testing mupdf lib64mupdf-devel | awk -F":" '{print $2}' | sort -u > mupdf.txt
$ urpmf poppler | awk -F":" '{print $2}' | sort -u > poppler.txt
$ comm -12 mupdf.txt poppler.txt

No results

$ mupdfinfo example.pdf
example.pdf:

PDF-1.4
Info object (40 0 R):
etc..

Testing complete x86_64 for mupdf-0.9-3.3.mga2.src.rpm

Whiteboard: (none) => mga2-64-OK

Man pages also checked, thanks malo for reminding me. mupdfinfo doesn't have a man page but mupdf, mupdfclean, mupdfdraw and mupdfshow are all ok.

Testing i586, MGA2.

mupdf 0.9-3.mga2 from core updates could not be installed, but when I activated core updates testing mupdf 0.9-3.3.mga2 was correctly installed. No poppler conflict, no man issue or anything else.

Status: ASSIGNED => NEW
CC: (none) => tolhildan_123

Update validated.
Thanks.

Advisory:
--------------

Updated mupdf package uses renamed executables to avoid a file conflict with
poppler, which prevented installation.

http://bugs.mageia.org/show_bug.cgi?id=6636
--------------

SRPM: mupdf-0.9-3.3.mga2.src.rpm

Could sysadmin please push from core/updates_testing to core/updates.

Thank you!

Status: NEW => ASSIGNED
CC: (none) => sysadmin-bugs

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGAA-2012-0111

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED