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!
--- Ralph Giles <giles@xiph.org> 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-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.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
--- Henrique de Moraes Holschuh <hmh@debian.org> 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
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 libOggFLAC 2:1:1 LibOggFLAC++ 1:1:1 1.1.1a (fixed sonames): libFLAC 6:1:0 libFLAC++ 6:1:0 libOggFLAC 2: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 libOggFLAC 2: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 libOggFLAC 3: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 libOggFLAC 3: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