On Wed, Sep 13, 2006 at 02:56:00PM +0100, Neil Williams wrote: > 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
Am I wrong in assuming that a binNMU of the current pilot-qof would pick up the new dependency automatically ? > 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. If dependencies are automatically generated by shlibdeps, then it is sufficient to binNMU all the packages affected: they will pick the correct dependencies by themself. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
