On Sun, Jan 09, 2005 at 02:03:28AM -0200, Henrique de Moraes Holschuh wrote:> *AND* there is a major problem with liboggflac1. > > liboggflac1 did not change the soname (better check this, it might require a > soname change, check the seekable ogg-flac support stuff).CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac? If so, it needs a soname change.> If it does, a new upload fixes it, and liboggflac1 should be generated by > the old-flac package. If it doesn't, then what should we do? libflac4 > would be mostly useless in that case. > > I will switch timidity to libflac6 in unstable, so that doesn't bother me > much, but flac is used by a lot of other stuff...I think it's best to just transition everything to current flac; it seems at least mostly backward-API-compatible (I haven't had to change anything so far, only recompile), and there aren't that many packages which use it. -- - mdz
On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote:> > liboggflac1 did not change the soname (better check this, it might require a > > soname change, check the seekable ogg-flac support stuff). > > CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac? > If so, it needs a soname change.Most of the changes were compatible, but it looks like some of the OggFLAC__StreamDecoderState enum entries changed position, so the soname should increment. Also, note that the file format changed to fix the streaming issues. liboggflac* prior to 1.1.1 is deprecated and debian should not support it. -r
OK, I'm coming to this a little late (been sick) but I'll try to answer all in one mail: On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote:> > liboggflac1 did not change the soname (better check this, it > might require a > > soname change, check the seekable ogg-flac support stuff). > > CCing upstream on this. Josh, did 1.1.1 change interfaces inliboggflac?> If so, it needs a soname change.as far as I can piece together, the last releases went like: FLAC release libOggFLAC went to ------------- ------------------------------------------ 1.1.0 1:2:0 from 1:1:0 (code changes only I think) 1.1.1-beta1 2:0:1 from 1:2:0 (some i'faces added, some changed) 1.1.1 2:1:1 from 2:0:1 (code changes only, no interface changes) I think this is all according to the libtool rules in http://www.gnu.org/software/libtool/manual.html#SEC35 the 'enum renumbering' to me implied an 'interface change' but maybe I misinterpreted. a more detailed list of what changed between 1.1.0 and 1.1.1 is here (scroll down to the libraries section): http://flac.sourceforge.net/changelog.html#flac_1_1_1 unfortunately I don't have anything that concise for earlier versions but I can dig it out of CVS if needed. --- Ralph Giles <giles@xiph.org> wrote:> 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.hmm... not sure what "exposed" means in the libtool numbering sense. the libOggFLAC++ includes do #include the libOggFLAC headers, but I have been (maybe erroneously) adjusting the libtool numbers strictly by what changed in the C++ side. --- Ralph Giles <giles@xiph.org> wrote:> Thank you. What I said about the enum was between 1.0.4 and 1.1.1. > But > you are correct. 1.1.0 has version-info 1:2:0 and also does not > include > the new streaming api or the enum reordering. So the update to 2:1:1 > in > the 1.1.1 release was incorrect. I should have been 2:0:0. (2:1:0 > works > too.)I don't see how it was wrong... but maybe FLAC 1.1.1-beta1 was the missing link. I don't know what the custom on numbering betas is, but flac-1.1.1-beta1 was public and people tend to live on the edge linking and shipping beta stuff, so I thought it was safest to treat it as a real version as far as libtool numbering goes. Josh __________________________________ Do you Yahoo!? All your favorites on one personal page – Try My Yahoo! http://my.yahoo.com
On Mon, Jan 10, 2005 at 09:37:18PM -0800, Josh Coalson wrote:> as far as I can piece together, the last releases went like: > > FLAC release libOggFLAC went to > ------------- ------------------------------------------ > 1.1.0 1:2:0 from 1:1:0 (code changes only I think) > 1.1.1-beta1 2:0:1 from 1:2:0 (some i'faces added, some changed) > 1.1.1 2:1:1 from 2:0:1 (code changes only, no > interface changes) > > I think this is all according to the libtool rules in > http://www.gnu.org/software/libtool/manual.html#SEC35 > > the 'enum renumbering' to me implied an 'interface change' > but maybe I misinterpreted.Yes, it's a change. The libtool manual seems a little incomplete here. This issue is that the order of items in the enum has changed in the header. Appending is generally safe, but because enums are mapped to integers in the object code, an app built against 1.1.0 would for example misinterpret what the 1.1.1 library uses for OggFLAC__STREAM_DECODER_OGG_ERROR as OggFLAC__STREAM_DECODER_END_OF_STREAM. As such it's an incompatible change, for which you should also zero the 'age' field. So 1.1.1-beta1 should have been 2:0:0, not 2:0:1.> http://flac.sourceforge.net/changelog.html#flac_1_1_1Thanks for the changelog link. That's very clear.> hmm... not sure what "exposed" means in the libtool numbering > sense. the libOggFLAC++ includes do #include the libOggFLAC > headers, but I have been (maybe erroneously) adjusting the > libtool numbers strictly by what changed in the C++ side.Hmm. Sounds like the same issue applies unfortunately. The real question is whether you can upgrade them independently or not. If not they should probably share libtool versioning numbers.> I don't know what the custom on numbering betas is, but > flac-1.1.1-beta1 was public and people tend to live on the edge > linking and shipping beta stuff, so I thought it was safest to > treat it as a real version as far as libtool numbering goes.Yes, I agree. The numbering is all about coexisting installs of the various versions. -r P.S. Hope you're feeling better!
On Sat, 08 Jan 2005, Ralph Giles wrote:> On Sat, Jan 08, 2005 at 08:31:47PM -0800, Matt Zimmerman wrote: > > > liboggflac1 did not change the soname (better check this, it might require a > > > soname change, check the seekable ogg-flac support stuff). > > > > CCing upstream on this. Josh, did 1.1.1 change interfaces in liboggflac? > > If so, it needs a soname change. > > Most of the changes were compatible, but it looks like some of the > OggFLAC__StreamDecoderState enum entries changed position, so the > soname should increment. > > Also, note that the file format changed to fix the streaming issues. > liboggflac* prior to 1.1.1 is deprecated and debian should not support > it.Sure. But since there is soname breakage, we need a completely correct package ASAP, since almost everything compiled against the current ones [that link to liboggflac*] will have to be recompiled. 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 :( BTW, since the mess is already big enough, please do a sanity check on the c++ bindings too. Maybe they ought to change the soname to keep in sync with the c libs they depend on ? -- "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