This was done because an application (pilot-qof) dependent on libqof1 requires libqof-backend-qsf0 but until 0.7.1, that was packaged within libqof1 itself, not separately.
The latest version of pilot-qof, 0.1.1-2, includes new dependency information: Depends: libc6 (>= 2.3.5-1), libglib2.0-0 (>= 2.10.0), libpisock9, libpopt0 (>= 1.10), libqof1, libqof-backend-qsf0 Recommends: xsltproc, xml-core, lynx | www-browser, dwww pilot-qof 0.1.1-2 depends on libpisock9 which was uploaded to unstable just last night. Once libpisock9 leaves incoming, pilot-qof 0.1.1-2 can be built for upload to unstable. The previous version, 0.0.10-1, was released before libqof-backend-qsf0 existed as a separate package. Once pilot-qof 0.1.1-2 moves into testing, the next upload of libqof1 will remove the dependency on the backends: Depends: libc6 (>= 2.3.5-1), libgda2-3, libglib2.0-0 (>= 2.10.0), libxml2 (>= 2.6.26), libxslt1.1 (>= 1.1.17) Recommends: libqof-backend-qsf0 | libqof-backend-gda0 | libqof-backend-sqlite0 Was there a better way of handling this situation where libfoo is split out from libbar? libbar must depend on libfoo - the problem was that foo (a completely separate application) depended on libfoo and expected libfoo to include libbar as well. pilot-qof is the only application to depend on the QSF backend and libqof1, gnotime depends on libqof1 but has it's own backend module. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
