On Sun, Jan 09, 2005 at 10:56:09AM -0800, Ralph Giles wrote:> On Sun, Jan 09, 2005 at 10:44:16AM -0200, Henrique de Moraes Holschuh wrote: > > > I am holding TiMidity in the current [broken] state until we get the new > > upstream with the soname fixes. I hope it is released very soon :( > > Are we talking about the library's soname, or the debian package name?The Debian library package is named after the soname.> Is the debian mismatch based on a release between these too? Should > flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding > all the packages against the 1.1.1 library should resolve the issue?If the interfaces changed, the soname (and thus the package) need to be renamed, and this needs to be done ASAP. If we can agree on the new soname, I can make that change immediately and upload new packages. -- - mdz
On Sun, Jan 09, 2005 at 11:05:45AM -0800, Matt Zimmerman wrote:> > Is the debian mismatch based on a release between these too? Should > > flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding > > all the packages against the 1.1.1 library should resolve the issue? > > If the interfaces changed, the soname (and thus the package) need to be > renamed, and this needs to be done ASAP. If we can agree on the new soname, > I can make that change immediately and upload new packages.I remain confused. You asked if the API had changed, I verified that it had changed and also pointed out that the soname defined in the makefile had been correspondingly incremented. Are you asking in addition for a new upstream release? -r
On Mon, Jan 10, 2005 at 12:22:18AM -0200, Henrique de Moraes Holschuh wrote:> Well, if something built against 1.0.4 can (even in corner cases) > malfunction with 1.1.1, then yes, it must be 2:1:0. This holds true to > the soname of the C++ libs too if changes on the underlying C libraries are > somehow exported through the C++ ones.Ok. One more time. liboggflac FROM THE 1.0.4 RELEASE has version-info 0:1:0 liboggflac FROM THE 1.1.1 RELEASE has version-info 2:1:1 That means current-age for the 1.1.1 liboggflac is 1. That means IT WILL NOT BE DYNAMICALLY LINKED to an application built against 1.0.4. THERE IS NO CONFLICT between these two versions. I don't see an upstream bug here, so if you're trying to report one you're going to have to be more explicit or I'm not going to be able to help you. I do appreciate the review of the always confusing library versioning scheme, but unfortunately it hasn't revealed any holes in my previous understanding. If, in fact, the underlying C library is somehow exposed in liboggflac++ then, as you suggest, we do have a problem there. Again, I need an authoritative statement if you want something done upstream. -r
On Sun, 09 Jan 2005, Matt Zimmerman wrote:> > Is the debian mismatch based on a release between these too? Should > > flac-1.1.1 release have been 2:1:0? In either case, it seems rebuilding > > all the packages against the 1.1.1 library should resolve the issue?Well, if something built against 1.0.4 can (even in corner cases) malfunction with 1.1.1, then yes, it must be 2:1:0. This holds true to the soname of the C++ libs too if changes on the underlying C libraries are somehow exported through the C++ ones. If stuff built against the old lib won't work with the new lib: increment soname and zero age ("backward incompatible change") ELSE If stuff built against the new lib won't work with the old lib: increment both soname and age ("forward compatible change") ELSE: leave the soname alone Simpler said than done, I know :( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh