Issues
The page should list cases in which GNOME modules do not seem to follow the Interface Specification.
General
GNOME release notes do not highlight what version of GNOME started following FreeDesktop specifications or how well the GNOME desktop manages backwards compatibility with the previous non-FreeDesktop way of doing things.
Known Issues
File Installation Locations
Status |
Module |
Bug |
Description |
Open Issue |
gnome-keyring-daemon |
gnome-keyring-daemon is installed to bin instead of libexec |
|
Open Issue |
General Issue |
General Issue |
Needless clutter in %{datadir}. One example, GNOME applications install datafiles to %{datadir}/programname just to install icon and glade files. Might make more sense to install these files to a common location like %{datadir}/icons and %{datadir}/glade. |
GNOME Website
Status |
Module |
Bug |
Description |
Open Issue |
Release Team |
Release Team Website Suggestions |
|
Open Issue |
libart_lgpl |
None |
The API docs for this GNOME Platform module are stored in a less stable/official location than other GNOME modules, http://www.gnome.org/~mathieu/libart |
Interface Documentation
Status |
Module |
Bug |
Description |
Partially Resolved |
GConf |
The gtk-docs are in poor shape |
|
Open Issue |
pango |
None |
gtk-docs do not seem to highlight interface change information |
Open Issue |
libart_lgpl |
Although API docs are provided at the above URL, the libart module does not build gtk-docs. Only 39 of the 108 functions exposed in libart are undocumented. The one added function is not using the "Since:" tag. |
|
Patch Available |
libglade |
One interfacce, glade_module_check_version is not documented |
|
Open Issue |
libgnome |
Not all libgnome interfaces are documented, and Since: tags are not properly used to indicate new interfaces] |
|
Open Issue |
libgnomeui |
Documentation bugs |
|
Open Issue |
gnome-vfs |
New interfaces not properly documented, gnome-vfs-mime move to libbonobo not mentioned |
Library Versioning
- Not all GNOME libraries follow a common library naming covention and it is not clear how a library should be renamed if the ABI changes. For example, the libgnomeprint library was named libgnomeprint-1.115 in 2.0, and libgnomeprint-2.2.z in GNOME 2.2 when its ABI changed. The GTK+ library instead changed the major release number when ABI has changed. It would be better to encourage more consistant renaming convention when ABI changes are introduced to a GNOME library.
- Some GNOME libraries contain a "-2" suffix while others do not. It is not necessarily a problem that different modules use different naming schemes, but the GNOME community should document what naming schemes are acceptable and how the names should change for each scheme.
MurrayCumming: Is there a real problem with a first version of an ABI not having a -1.0 suffix, or would that solve any real problem? BrianCameron: The problem is that GNOME does not have clear naming conventions that should be followed when new files integrate into the GNOME desktop. It would be better if there were a more clear naming standard to avoid clutter and have more consistancy in terms of file naming. Libraries are just one example; another example would be the %{datadir} issue described above where some icons are installed to %{datadir}/icons and others are installed to %{datadir}/projectname. I'm sure there are more opportunities to encourage project in GNOME to follow standards to create a less cluttered filesystem footprint.
libtool
The GNOME Release Team recommends that the LT_VERSION macro be updated in their instructions for Making A Release. Note that some GNOME Platform modules do not follow this recommendation, but probably should. ORBit2, libbonobo, and libbonoboui are examples of modules that have not been following this convention as their interfaces change.
The following text explains how the LT_VERSION libtool macro is used to control library version numbers.
# Before making a release, the LT_VERSION string should be modified. # The string is of the form C:R:A, or CURRENT[:REVISION[:AGE]] . # - If interfaces have been changed or added, but binary compatibility has # been preserved, change to C+1:0:A+1 # - If binary compatibility has been broken (eg removed or changed interfaces) # change to C+1:0:0 # - If the interface is the same as the previous version, change to C:R+1:A LT_VERSION=4:5:2
This is then passed to libtool's -version-info argument. Owen Taylor has the following to say explaining why this is valuable.
OwenTaylor: The standard libtool scheme maps in a predictable (if unituitive way) to the ELF version triplet, and gives you no capabilities that you wouldn't have by specifying that version number directly. The only things that really matter is: does the soname change? (the soname is typically libfoo.so.x). We jump through some hoops in the GTK+ stack to give library version numbers that are more easily connectable to the release versions ... so we have, say, libgtk-2.0.so.0.800.2 for gtk+-2.8.2, but the important thing is that "libgtk-2.0.so.0" has stayed constant since GTK+-2.0.0. If we broke backwards compatibility, then we would change the soname, but that would generally be a bad thing. If we were using the libtool versioning scheme more directly, then we'd likely have something like libgtk.so.3.7.2 as the version number, which would be fine as well, as long as 'libgtk.so.3' hadn't changed since GTK+-2.0.0. The reason that libtool has a bizarre scheme rather than specifying ELF numbers is to increase portability systems with different conventions (SunOS 4, old BSD systems only have x.y, not x.yz). Though recent versions of libtool let you specify ELF triplets directly as an alternatively.