Le dimanche, 9 juin 2013 15.08:12, Bill Allombert a écrit : > On Sun, Jun 09, 2013 at 02:19:51PM +0200, Didier 'OdyX' Raboud wrote: > > Control: tags -1 +moreinfo > > > > Hi Bill, and thanks for your bugreport, > > > > Le samedi, 8 juin 2013 21.31:32, Bill Allombert a écrit : > > > There is a circular dependency between libcupsfilters1 and > > > libcupsimage2: > > > > > > libcupsfilters1 :Depends: libcupsimage2 (>= 1.4.0) > > > libcupsimage2 :Depends: libcupsfilters1 (>= 1.0~b1) > > > > Indeed. Good catch, thanks. > > > > > Circular dependencies involving shared libraries are known to cause > > > problems during upgrade between stable releases, so we should try to > > > get rid of them. > > > > The problem here is that the ABI provided by libcupsimage2 has been split > > at version 1.6 between libcupsimage2 and libcupsfilters1, hence the > > depends of libcupsimage2 on libcupsfilters1. > > But libcupsfilters1 already exist in wheezy, so this more a transfer than a > split ? A split would be more easily dealt with. Indeed, it's a transfer of symbols without SOVERSION bump. I don't particularily like it, but it's there… > > This could probably be downgraded to a > > Recommends, but brings in the risk that package A, depending on > > libcupsimage2 1.5 stops to work if libcupsimage2 is upgraded to 1.6 and > > libcupsfilters1 is not installed (aka partial upgrade). > > I'd like to be convinced the dependency is actually sufficient to fix > partial upgrade, especially since dpkg will have to break the circular > dependency anyway. Fair enough, but the dependencies ensure that dpkg is only happy with the two libraries installed at the same time, so the window of brokenness opportunity is quite small. > It might be necessary to introduce an extra package. What package do you have in mind? > Is there packages in wheezy that use the libcupsimage2 symbols that are now > in libcupsfilters1 but do not depend on libcupsfilters1 ? As for the symbols I don't know (but could probably given more work), but these reverse dependencies (from other source packages) are in place in Wheezy: libcupsimage2-dev ← libgs-dev libcupsimage2 ← cups-filters, depends on libcupsfilters1 libcupsimage2 ← libcupsfilters1 (shlibs dependency, can't be removed) libcupsimage2 ← ghostscript-cups, doesn't depend on libcupsfilters1 libcupsimage2 ← libescpr1 (dropped in Jessie) libcupsimage2 ← libgs9, doesn't depend on libcupsfilters1 libcupsimage2 ← lsb-printing, doesn't depend on libcupsfilters1 [0] libcupsimage2 ← printer-driver-c2esp, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-escpr, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-gutenprint, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-hpcups, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-ptouch, doesn't depend on libcupsfilters1 libcupsimage2 ← printer-driver-splix, doesn't depend on libcupsfilters1 So only cups-filters seems fine, for good reasons. How can I check which symbols are used by each package without rebuilding with a special set of packages? Cheers, OdyX [0] LSB only mandates these symbols, all in libcupsimage2: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Printing/LSB- Printing/libcupsimage.html
Attachment:
signature.asc
Description: This is a digitally signed message part.