Description of problem: Broken dependencies when trying to install texlive in dist-f12-build tag in koji. When trying to build new packages for Fedora 12 that uses latex as a build requirement, the setup of the build environment fails: DEBUG util.py:256: texlive-2007-42.fc11.x86_64 from build has depsolving problems DEBUG util.py:256: --> Missing Dependency: libpoppler.so.4()(64bit) is needed by package texlive-2007-42.fc11.x86_64 (build) DEBUG util.py:256: Error: Missing Dependency: libpoppler.so.4()(64bit) is needed by package texlive-2007-42.fc11.x86_64 (build) Version-Release number of selected component (if applicable): texlive-2007-42.fc11 (when installed in dist-f12-build) How reproducible: Always Steps to Reproduce: Start a koji build in dist-f12-build that uses latex as a BuildRequires Actual results: Setup of build environment fails due to broken dependencies Expected results: Working build environment Additional info: The new version of the poppler package that is the reason for the broken dependencies was completed Tue, 19 May 2009 15:03:19 UTC This new version has a new soname: /usr/lib/libpoppler.so.5
Hmmm, seems like the new poppler breaks texlive build a bit: http://koji.fedoraproject.org/koji/getfile?taskID=1365524&name=build.log Need to have a look what happened on poppler side to fix the poppler-dependent texlive utilities.
Gathering some information from various sources - if you find it useful: Here is the poppler commit that makes the destructor for the GfxFont object protected: http://cgit.freedesktop.org/poppler/poppler/commit/?id=80f415176952635a485356cf36048eee53396c25 with the commit comment: "Make destructors private/protected since you are not supposed to use them" The koji compilation in comment #1 of texlive fails with: /usr/include/poppler/GfxFont.h: In function 'void writeEncodings()': /usr/include/poppler/GfxFont.h:230: error: 'virtual GfxFont::~GfxFont()' is protected pdftoepdf.cc:636: error: within this context So the texlive code uses the destructor anyway. Maybe the right thing to do is use the decRefCnt() method on the GfxFont object rather than deleting it. This guess (and it is nothing more than a guess from my side) is based on the change to the GfxFont.cc file in the same poppler commit above that made the destructor protected in GfxFont.h. That is to change the line that fails compilation from: delete r->font; to: r->font->decRefCnt();
Yup, you are right, it seems it fixes it. Actually the poppler commit itself suggests that :) Thanks for the link to poppler commit!