Why does the fitz backend depend on app-text/mupdf:0/1.4 ? I tested qpdfview 0.4.14 with mupdf 1.6 and everything seems to work fine. Reproducible: Always
Franz, can you shed some light on this?
I had a look at the CHANGES file from mupdf. It usually lists accurately what changed API-wise. There were some API-changes in 1.4, but since then (v1.5, v1.6) there were none listed. So IMHO qpdfview should also build with mupdf:1.6. However there may be ABI breakage, so forcing a rebuild of qpdfview after a mupdf-bump is needed - which the subslot-dep should handle just fine. So I personally don't see any issues to allow >=mupdf-1.4 as a dep. But we should then watch for API changes in future mupdf releases (and how/if qpdfview adapts to them).
mupdf:1.7 is out and there were API changes, again. If you e.g. look at zathura-pdf-mupdf they now added a "<mupdf:1.7" restriction. IMHO that should work for qpdfview, too.
Rev 1884 (from 12. April) introduced support for mupdf:1.7. It is then a hard requirement. So the next qpdfview-release will have to depend on mupdf:1.7.
(In reply to Franz Fellner from comment #4) > So the next qpdfview-release will have to depend on > mupdf:1.7. IIUC, >=app-text/mupdf-1.7:= makes more sense
Just wanted to point out that the version bump to qpdfview-0.4.14 still depends on >=mupdf-1.4. Should be 1.7 now.
Fixed in qpdfview-0.4.15.ebuild now. I have removed 0.4.14.