Re: [Flac-dev] liboggflac1 soname
On Mon, 24 Jan 2005, Josh Coalson wrote: > OK, I am going to do a 1.1.2 earlier than I wanted in order to > fix this. anyway there are some bug fixes and speedups that will > be of benefit. > > because of the mess and since there have been API changes and > additions in both libFLAC and libOggFLAC since 1.1.1 I plan on > bumping all the libtool numbers as follows: current++, revision=0 > age=0. if this will cause problems please let me know. That'll be perfect. Thank you! -- "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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
On Mon, 10 Jan 2005, Ralph Giles wrote: > 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. [...] > Yes, I agree. The numbering is all about coexisting installs of the > various versions. Ok. I need to know what to do about this... is 1.1.2 with fixed sonames just around the corner? What should we do to fix sonames in Debian? I really don't want to upload a new timidity linked to liboggflac with broken sonames, and I really, really don't want to see libraries which will cause soname headaches make it to the next debian stable (speaking as an user of said libraries). Do we have a consensus that: 1. the C++ libs should increase sonames in SYNC with the C ones because some of the ABI is leaked through them. This means that at least libOggFLAC++ has a wrong soname in 1.1.1, and that it would be a good idea to do an initial sync of all sonames with the non-C++ libs to fix this for good. After the initial sync, increasing the C lib sonames means the C++ sonames have to be increased as well (and zeroing the C lib AGE means the C++ ones need to be zeroed as well). The C++ libs can increase soname/zero AGE without increasing the C lib ones in the case of C++ specific changes, of course. 2. the AGE of liboggflack should be zeroed in 1.1.1, and thus if 1.1.2 shows futher ABI changes, it will increase the soname (and keep AGE 0). That would mean sonames like this: 1.1.1 (released with broken sonames): libFLAC 6:1:0 libFLAC++ 4:1:0 libOggFLAC2:1:1 LibOggFLAC++ 1:1:1 1.1.1a (fixed sonames): libFLAC 6:1:0 libFLAC++ 6:1:0 libOggFLAC2:1:0 LibOggFLAC++ 2:1:0 1.1.2 (assuming *NO* ABI changes from 1.1.1): libFLAC 6:1:0 libFLAC++ 6:1:0 libOggFLAC2:1:0 LibOggFLAC++ 2:1:0 1.1.2 (assuming there ARE forward-compatible ABI changes in the C libs, and optional also forward-compatible ABI changes to the C++ libs): libFLAC 7:1:1 libFLAC++ 7:1:1 libOggFLAC3:1:1 LibOggFLAC++ 3:1:1 1.1.2 (assuming there ARE backward-incompatible ABI changes in the C libs): libFLAC 7:1:0 libFLAC++ 7:1:0 libOggFLAC3:1:0 LibOggFLAC++ 3:1:0 Can we agree on the above soname plan, so that we can start fixing the Debian packages (other distros might want to follow this fix, as well...) ? -- "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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
On Sun, 09 Jan 2005, Ralph Giles wrote: > On Mon, Jan 10, 2005 at 12:22:18AM -0200, Henrique de Moraes Holschuh wrote: > 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 Well, the packages we are having trouble here are: flac 1.1.0 (let me check... libOggFLAC version-info 1:2:0) debian package: liboggflac1 (matches libtool soname - ok) oggflac 1.1.0 not forward or backwards compatible with 1.0.4 -> ok. oggflac 1.1.1 not forward or backwards compatible with 1.1.0 -> problem. So, it looks to me that liboggflac 1.1.1 should have version-info 2:1:0. This is based on what you told us about the OggFLAC__StreamDecoderState enum entries changing position. > If, in fact, the underlying C library is somehow exposed in > liboggflac++ then, as you suggest, we do have a problem there. I didn't check for that one. If you believe there is not, then I have no reason to think there is a leak. It was just a heads'up since we were talking about such issues anyway... > Again, I need an authoritative statement if you want something > done upstream. There it is: in light of the possible enum problem with liboggflac from 1.1.0 to 1.1.1 you told us about, the version-info of liboggflac 1.1.1 should be changed upstream to 2:1:0, please. -- "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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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
___
Flac-dev mailing list
Flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
On Mon, Jan 24, 2005 at 05:43:04PM -0800, Josh Coalson wrote: > because of the mess and since there have been API changes and > additions in both libFLAC and libOggFLAC since 1.1.1 I plan on > bumping all the libtool numbers as follows: current++, revision=0 > age=0. if this will cause problems please let me know. That should resolve the issues. Thanks. -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
--- Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > On Mon, 10 Jan 2005, Ralph Giles wrote: > > 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. > [...] > > Yes, I agree. The numbering is all about coexisting installs of the > > > various versions. > > Ok. I need to know what to do about this... is 1.1.2 with fixed > sonames > just around the corner? What should we do to fix sonames in Debian? OK, I am going to do a 1.1.2 earlier than I wanted in order to fix this. anyway there are some bug fixes and speedups that will be of benefit. because of the mess and since there have been API changes and additions in both libFLAC and libOggFLAC since 1.1.1 I plan on bumping all the libtool numbers as follows: current++, revision=0 age=0. if this will cause problems please let me know. I'll try to get this ready as soon as possible. Josh __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
--- Ralph Giles <[EMAIL PROTECTED]> wrote: > 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-beta12: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. I still don't see why it should have been 2:0:0... some interfaces were added, and some were changed, and none removed, so according to those doc's steps: 3. code changed => 1:2:0->1:3:0 4. i'faces added&changed => 1:3:0->2:0:0 5. i'faces added => 2:0:0->2:0:1 6. no i'faces removed so I still don't see how the numbering could have broken something or how I would fix it in the next release. unless: > > http://flac.sourceforge.net/changelog.html#flac_1_1_1 > > Thanks 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. ...maybe this is what caused the problem? i.e. some underlying change in libFLAC. also, just read Henrique's later email... this is probably what happened. for the next release I will make sure that the numbers are bumped up enough to be right again. but I don't have a timeline for the next release... it is mostly ready but I'm still trying to get time to integrate a bunch of PPC optimizations. I'm OK with Matt doing a 1.1.1a just to fix the sonames though. Josh __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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-beta12: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_1 Thanks 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! ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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 in liboggflac? > 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-beta12: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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
On Mon, Jan 10, 2005 at 01:36:23AM -0200, Henrique de Moraes Holschuh wrote: > Well, the packages we are having trouble here are: > flac 1.1.0 (let me check... libOggFLAC version-info 1:2:0) > debian package: liboggflac1 (matches libtool soname - ok) > > oggflac 1.1.0 not forward or backwards compatible with 1.0.4 -> ok. > oggflac 1.1.1 not forward or backwards compatible with 1.1.0 -> problem. > > So, it looks to me that liboggflac 1.1.1 should have version-info 2:1:0. > This is based on what you told us about the OggFLAC__StreamDecoderState enum > entries changing position. 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.) > > If, in fact, the underlying C library is somehow exposed in > > liboggflac++ then, as you suggest, we do have a problem there. > > I didn't check for that one. If you believe there is not, then I have no > reason to think there is a leak. It was just a heads'up since we were > talking about such issues anyway... As I said, I'm not qualified to evaluate this. Josh, got a comment on this? Want me to do a 1.1.2 to resolve this? -r ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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? I compared the 1.1.1 release with 1.0.4, which I think was the last stable version. The version-info increments acceptably between the two releases, from 0:1:0 to 2:1:1. Obviously revision hasn't always been incremented properly, at the very least, and I don't know when we went throught current=1. 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? > 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 ? I don't know C++ well enough to evaluate ABI compatibility. The version- info for libOggFLAC++ moved from 0:1:0 to 1:1:1 between 1.0.4 and 1.1.1. Can someone else comment on this? -r (not a flac developer, just trying to be helpful.) ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] liboggflac1 soname
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] liboggflac1 soname
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 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
