GNOME Bugzilla – Bug 504220
Are names, locations in libgoffice 0.6.0 correct?
Last modified: 2007-12-19 12:57:47 UTC
I'm wondering about the following in libgoffice-0.6.0. (Actually, it's svn HEAD from after libgoffice-0.6.0 was uploaded) goffice include files still install into $prefix/include/libgoffice-0.5. the solib is named libgoffice-0.5.so.6 etc. Should those be 0.6 instead?
This is controlled by libgoffice-0.5.pc.in, which also should be renamed to libgoffice-0.6.pc.in, I guess. Likewise, GOFFICE_PLUGIN_LIBADD and AC_CONFIG_FILES in configure.in mention libgoffice-0.5.
Created attachment 101172 [details] [review] Untested.
Please do not change the library name without good reasons (which I don't see presented here yet). Changing library names is not the right mechanism for dealing with (potential) compatibility issues between different versions and can cause major headaches for packagers like myself. The right mechanism is proper use of libtool's CURRENT:REVISION:AGE versioning scheme as used by e.g. glib. glib's library name, libglib-2.0, was fixed a long time ago and is nowadays unrelated to the glib source package version number (2.14.4). The compatibility info is in the full library file name, libglib-2.0.so.0.1400.4, and in the SONAME in that file (libglib-2.0.so.0).
Changing the library name *IS* the right way to deal with incompatibilities, if you look at this from the packagers point of view, and goffice is a perfect example. * AbiWord 2.4.6 (the current stable version) deps goffice-0.2.x (libgoffice-1). * GNOME Chemistry Utils deps goffice-0.4.x (libgoffice-0.4). * Gnumeric 1.8 will dep goffice-0.6.x (libgoffice-0.6). Because of extensive API changes in each branch, any of the above will not *build* with another branch of goffice. It is not just enough to have parallel-installable runtimes, but the entire library must be versioned to allow all three to coexist. While I'm sure that AbiWord and GChemUtils will eventually migrate to newer versions, allowing distros to drop the older goffice branches, in the meantime this is the proper solution. What I would suggest is not making separate versioning for development branches, e.g. when goffice is branched for 0.7->0.8 development, just call everything 0.8, and if you want to assure that you have the stable version, just dep 'libgoffice-0.8 >= 0.8.0'.
And BTW, glib DOES use this technique, as does most of GNOME, to differentiate between 1.x and 2.x.; likewise GStreamer with 0.6, 0.8, 0.10, etc. This is the essay I was looking for before on this topic, which makes the point at greater length: http://www106.pair.com/rhp/parallel.html
Abiword and gchemutils will not migrate to goffice-0.6 i the immediate because of the lack of gnome-print support, at least until we have cairo support in abiword (not before abiword-2.8.0), so we must live with both versions (0.4 and 0.6) for a while, this is why it is important to have different library names for the two versions. Jody, there is still something wrong after applying your patch: plugins are installed to $(libdir)/goffice//plugins so the version is missing. I'll investigate later, need to go to work.
Created attachment 101235 [details] [review] auto versioning patch Better yet, I want to withdraw my last paragraph in comment 4, and propose another solution instead, with a patch based on Jody's in comment 2, but with a more permanent fix. GStreamer avoids this kind of "forgot to change the version before release" issue by automating the process via using @GST_MAJORMINOR@ throughout instead of a number, which is replaced appropriately with an AC_SUBST. Unlike using $(), which won't work in a lot of places, the @@ substitution works with automake because it sees this literally, e.g. automake thinks the library is exactly 'libfoo-@VERSION@.la', at-signs and all, for Makefile.in, but the AC_SUBST replaces this in Makefile. The other problem, with the constant renaming of the .pc.in file (which, at least with CVS, means rm'ing one file and add'ing a second), is solved by using by starting with an unversioned file, and versioning it with during make; IIRC gtk+ does this as well, wrt the various toolkits. While this means that there will be a separate 0.7 and 0.8 (just as GStreamer had parallel 0.9 and 0.10), even though the former really just leads to the latter, automating the process is surely worth it. The attached patch implements this, and was tested with the 0.6.0 tarball and fixes everything except for paralleling the gtk-docs. The latter will have to be dealt with separately. (While I was at it, I also included the fix for the other issue in 504238.) * Makefile.am: Distribute dumpdef.pl; fixes bug 504238. * Makefile.am: * configure.in: * docs/reference/Makefile.am: * goffice.mk: * goffice/Makefile.am: * goffice/cut-n-paste/foocanvas/Makefile.am: * libgoffice.pc.in: Define correct branch versioning automatically with GOFFICE_MAJORMINOR; fixes bug 504220. * libgoffice-0.5.pc.in: Removed. * goffice/gtk/goffice-gtk.h: Push off removal of deprecated go_libglade_new.
In light of Yaakov's comments and after reexamining the goffice transition I'm dealing with (http://bjorn.haxx.se/debian/testing.pl?package=goffice;expand=1), I withdraw my objections (comment #3). Please go with his auto versioning patch (comment #7) and release a 0.8.1 with it. As for the gtk-doc files, to my knowledge documentation browsers like yelp have no explicit support for multiple versions of documentation, so I think this needs to be left to the packagers. In my case, I'll include the docs in the development package of the latest version and strip them from the development packages of older versions.
The plugindir issue was a local issue. The patch seems correct.
Comment on attachment 101235 [details] [review] auto versioning patch - dropped the dumpdefs.pl change in favour of the other patch - renamed MAJORMINOR -> APIVER and hard coded it in configure.in so that we can use the next stable api during a development cycle. (eg 0.7 will be called 0.8) to give packagers maximal time to get the new lib into production. - and applied the remainder, nice work.
patched the import tools also.
RE: comment 8, there ARE ways to have multiple versions of documentation for the same library: 1) Manually, by (with goffice) changing DOC_MODULE to goffice-$(GOFFICE_APIVER) and 'rename goffice goffice-0.6 docs/reference/goffice*', then add the version number into docs.sgml accordingly. gnome-vfs2 and gtksourceview2 use this method, but this would require manual renaming of the files with every development branch. 2) GStreamer uses a customized gtk-doc.mak file (in common/) which adds a few tricks to handle this automatically; the original files are unversioned, TARGET_DIR is overridden, and the .devhelp* files are versioned during install-data-local. I would like to see this fixed, but in which way would you prefer? RE: comment 10, thank you, I presume 0.6.1 will be soon forthcoming with this fix?