Re: API break / so versioning
On Mon, 2008-06-02 at 09:44 +0300, Tambet Ingo wrote: > On Fri, May 30, 2008 at 9:31 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-05-30 at 20:13 +0200, Michael Biebl wrote: > >> What you can easily notice (by running a diff), ist that not only a lot > >> of symbols were added, but also quite a few were removed, which could > >> result in application crashes. In case of an API break, you usually bump > >> the SOVERSION, which leads to the more general question, if NM shouldn't > >> start using proper soversioning [1]. > > > > Yes, it probably should. One thing that we've tried to do is keep the > > old libnm_glib symbols around though, which is why we kept the > > libnm_glib name instead or renaming it to libnm-glib instead. So that > > at least apps that used the old basic 0.6 API bits would still work. > > There's probably no point in keeping that anymore. The basic API is > kept, but some of the basic defined variables have changed > (NMDeviceState), so even if something might still compile, it probably > doesn't work anymore. I think some apps still use it (evolution maybe?), though that may be a custom Fedora patch. We could build the old bits into the .so.0 and all the new bits into the .so.1 perhaps? Dan > > If we're willing to ditch that assumption, then I'm all for removing > > that code and bumping the soname. > > > >> I also wondered, if the separate library libnm_glib_vpn.so.0 is really > >> necessary or should be folded into libnm_glib.so.0. > > > > This is used by the VPN services and isn't really part of the same bits > > that should be used by clients of NM. I tend to think we should keep > > them separate, since if you're writing a client like nm-applet you > > shouldn't care about anything that's in libnm_glib_vpn. Maybe Tambet > > has more thoughts? > > Yes, these should be separate. One (libnm-glib) is part of the client, > the other (libnm-glib-vpn) part of the daemon. > > Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API break / so versioning
On Fri, May 30, 2008 at 9:31 PM, Dan Williams <[EMAIL PROTECTED]> wrote: > On Fri, 2008-05-30 at 20:13 +0200, Michael Biebl wrote: >> What you can easily notice (by running a diff), ist that not only a lot >> of symbols were added, but also quite a few were removed, which could >> result in application crashes. In case of an API break, you usually bump >> the SOVERSION, which leads to the more general question, if NM shouldn't >> start using proper soversioning [1]. > > Yes, it probably should. One thing that we've tried to do is keep the > old libnm_glib symbols around though, which is why we kept the > libnm_glib name instead or renaming it to libnm-glib instead. So that > at least apps that used the old basic 0.6 API bits would still work. There's probably no point in keeping that anymore. The basic API is kept, but some of the basic defined variables have changed (NMDeviceState), so even if something might still compile, it probably doesn't work anymore. > If we're willing to ditch that assumption, then I'm all for removing > that code and bumping the soname. > >> I also wondered, if the separate library libnm_glib_vpn.so.0 is really >> necessary or should be folded into libnm_glib.so.0. > > This is used by the VPN services and isn't really part of the same bits > that should be used by clients of NM. I tend to think we should keep > them separate, since if you're writing a client like nm-applet you > shouldn't care about anything that's in libnm_glib_vpn. Maybe Tambet > has more thoughts? Yes, these should be separate. One (libnm-glib) is part of the client, the other (libnm-glib-vpn) part of the daemon. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API break / so versioning
On Fri, 2008-05-30 at 20:13 +0200, Michael Biebl wrote: > Hi, > > in Debian we have a nice facility which allows to track the exported > symbols of a shared library. Attached are the symbols files of > libnm-util and libnm-glib for current NM 0.6.6 and NM 0.7.0~svn3712. > > What you can easily notice (by running a diff), ist that not only a lot > of symbols were added, but also quite a few were removed, which could > result in application crashes. In case of an API break, you usually bump > the SOVERSION, which leads to the more general question, if NM shouldn't > start using proper soversioning [1]. Yes, it probably should. One thing that we've tried to do is keep the old libnm_glib symbols around though, which is why we kept the libnm_glib name instead or renaming it to libnm-glib instead. So that at least apps that used the old basic 0.6 API bits would still work. If we're willing to ditch that assumption, then I'm all for removing that code and bumping the soname. > I also wondered, if the separate library libnm_glib_vpn.so.0 is really > necessary or should be folded into libnm_glib.so.0. This is used by the VPN services and isn't really part of the same bits that should be used by clients of NM. I tend to think we should keep them separate, since if you're writing a client like nm-applet you shouldn't care about anything that's in libnm_glib_vpn. Maybe Tambet has more thoughts? > And last but not least, skimming through libnm-glib0-0.7.0.symbols, > there are quite a few autogenerated symbols like > nm_marshal_VOID__OBJECT... > Are those expected to be part of the public API? Nope. There's probably a lot of symbols that aren't part of the public API. In the end, the public API is defined by the installed .h files. I haven't done any symbol visibility yet because that's a PITA to set up and maintain and makes debugging harder, but it's likely something we should be doing in the near future. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
API break / so versioning
Hi, in Debian we have a nice facility which allows to track the exported symbols of a shared library. Attached are the symbols files of libnm-util and libnm-glib for current NM 0.6.6 and NM 0.7.0~svn3712. What you can easily notice (by running a diff), ist that not only a lot of symbols were added, but also quite a few were removed, which could result in application crashes. In case of an API break, you usually bump the SOVERSION, which leads to the more general question, if NM shouldn't start using proper soversioning [1]. I also wondered, if the separate library libnm_glib_vpn.so.0 is really necessary or should be folded into libnm_glib.so.0. And last but not least, skimming through libnm-glib0-0.7.0.symbols, there are quite a few autogenerated symbols like nm_marshal_VOID__OBJECT... Are those expected to be part of the public API? Please share your comments. Cheers, Michael [1] http://www.gnu.org/software/libtool/manual.html#Versioning -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? libnm_glib.so.0 libnm-glib0 #MINVER# [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.6 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 libnm_glib.so.0 libnm-glib0 #MINVER# [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.6.4 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED] 0.7.0~svn3712 [EMAIL PROTECTED
