Hi Steve, On Fri, Nov 24, 2006 at 09:47:18PM -0800, Steve Langasek wrote: > So looking at libgeda for bug #400252 brings another RC bug to my attention: > you have not been changing your library package name in keeping with the > soname changes of this library, and the shlibs provided by libgeda reference > this same, unchanging package name, which means any packages built against > an older version of the package will be installable but broken when a new > soname of the lib is available. > > Evidently you've worked around this in all the in-archive packages that > depend on libgeda by adding versioned conflicts each time a new version of > libgeda comes out, which explains some of the other release-critical bugs > I've seen in the past. This is technically sound for those packages in > Debian, albeit high-maintenance and aesthetically displeasing; but shlibs > files must contain sufficient information that *others* get correct > dependencies when linking against your library as well, which is currently > not the case.
Yes you are quite right. libgeda conflicts with old versions of the binaries and the binaries depend on a sufficient version of the library, the end result being a tight coupling between the versions. This works as long as all of the applications are released together, which currently they are. Upstream originally released just one tarball, but now release individual tarballs for each application - but as a matching set, like the Debian binary packages. > In addition, since there are no file overlaps between subsequent versions of > libgeda, this breaks co-installability of packages built against different > versions of libgeda for no apparent reason. If there *were* file conflicts > between the different versions, I would say that your use of Provides: is a > perfectly reasonable technical solution and that the only thing in need of > fixing is the shlibs file, but as it stands I think this is a gratuitous > deviation from Debian library best practices. Please fix libgeda so that > the library package name matches the soname, and update the shlibs to match. > Although this does mean new upstream versions of libgeda will have to go > through the NEW queue, it also should require much less packaging work on > the whole when updating... This was a working for slow NEW processing, and also for the perception that repeated NEW processing was a bit of a nuisance in this case because the packages are always a matched set. This is definitely a case where it would be nice if NEW processing only applied for new sources, not just new binaries. I do agree that it's a horrid violation of policy though. > The library package name is not a release-critical issue, BTW, so if you > insist on keeping this package name, geda won't be kicked from the release > because of it. But the shlibs do need to be fixed. The shlibs for libgeda20 20061020 says libgeda 27 libgeda20 (>= 20061020) I think this is correct - it means a sufficient version of libgeda20 is used in the Dependences of geda-gattrib et al. In itself it doesn't prevent a later incompatible version of libgeda meeting the dependency, but the new libgeda will Conflict with old applications. The only improvement I see would be to specify (>= 20061020) && (< 20061021~0) or similar in the shlibs file. Then libgeda's would no longer need to conflict with old versions (though the existing conflicts would need to stay). Is this your recommendation? I have libgeda providing virtual package libgeda-27, but unfortunately dpkg has a bug where it doesn't prevent libgeda20 being upgraded if it no longer provides virtual packages required by other installed packages. Else I could just use libgeda-NN in the shlibs file. Thanks, Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
