[Pkg-qof-maintainers] Bug#387196: circular dependency

[Bill Allombert]

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. <ballombe at debian.org>

Imagine a large red swirl here.