GNOME Bugzilla – Bug 341802
Make Evolution installed directories names without version
Last modified: 2014-09-08 17:23:37 UTC
Please describe the problem: Our first concern here is: We notice that there are several versioned-directories installed by Evolution in /usr/include, /usr/lib and /usr/share, like /usr/lib/evolution-data-server-1.2, /usr/include/evolution-2.6. We understand that this is thus designed to accommodate coexistence of multiple version. However, we think there is another possible solution to make coexistence of multiple versions possible, and which is better as far as we are concerned. Like what we have done with the evolution libs in /usr/lib (they are all put in to /usr/lib/evolution/$version-number instead of /usr/lib/evolution-$version-number). In this way, all this files can be placed in directories that easily get cluttered. For example, in our opinion this is good: /usr/share/evolution/1.x/ /usr/share/evolution/2.x/ This is bad /usr/share/evolution-1.x /usr/share/evolution-2.x It is bad because this clutters up a directory (/usr/share) that many different projects install to. If a project installs version numbered stuff, they should install it to private locations that are specific to the application (such as /usr/share/evolution). The current status of Evolution installed directories are: /usr/lib/evolution/2.x /usr/libexec/evolution/2.x /usr/share/evolution/2.x and /usr/include/evolution-2.6 =>/usr/include/evolution/2.6 /usr/include/evolution-data-server-1.6 =>/usr/include/evolution-data-server/1.6 /usr/include/libgtkhtml-3.8 =>/usr/include/libgtkhtml/3.8 /usr/include/libsoup-2.2 =>/usr/include/libsoup/2.2 /usr/lib/evolution-data-server-1.2 =>/usr/lib/evolution-data-server/1.2 /usr/share/evolution-data-server-1.6 =>/usr/share/evolution-data-server/1.6 Our proposal is to change all those in second part into those after the "=>", so that better consistency can be achieved. We'd appreciate comments on this proposal. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
This *is* a Good Thing To Do. Need to figure out who might get affected due to this change, notify them appropriately. (Upgrade/Migration scripts, configuration checks etc). I am targeting this for 2.8.
Created attachment 65646 [details] [review] patch for evolution-data-server
Created attachment 65647 [details] [review] patch for gtkhtml
*poke* Will this be done in time? Also, does this seriously block GNOME 2.16?
Yes. I am still awaiting inputs from a few stakeholders - the proposed solution is good but the change itself necessitates an impact review. If I do not hear from them by Monday, I am going ahead with the change. OTH, this *is not* a blocker - as per severity and priority. Per description of the Gnome Target field, " This is not a 'it would be nice' field, it's a 'Gnome releases may need to be delayed for this issue' field. " Setting it to unspecified.
Looks good to me. Srag, can you test this independently and confirm too..TIA
er..this seems to be incomplete wrt idl and includes..
postponing to an early stage of 2.9.
Please also consider the impact of version-specific directories on users' configuration data when upgrading from one major release to the next. In some cases I think it's better not to have a version number in the directory path at all. The directory /usr/share/pixmap/evolution-data-server-1.x is one such example. Bug #351930 describes the problem this creates for users.
Bumping version to a stable release.
Bringing this back to life. I'd like to drop version-numbered directories entirely for 2.30. Users don't run multiple Evolution versions at once on the same machine and developers who do so should be using different install prefixes. Let's stop pretending that we support this. /usr/share/gtkhtml-3.14/ --> /usr/share/gtkhtml/ /usr/lib/evolution-data-server-1.2/ --> /usr/lib/evolution-data-server/ /usr/share/evolution-data-server-2.26/ --> /usr/share/evolution-data-server/ /usr/lib/evolution/2.26/ --> /usr/lib/evolution/ /usr/share/evolution/2.26/ --> /usr/share/evolution/ The changes will be transparent for packages that use pkg-config. Packages that don't use pkg-config are broken anyway. Note that I'm leaving library names alone. This is for directories only.
I've had a change of heart about the Evolution library directory. The libraries there don't use libtool versioning and have no backward compatibility guarantees, so the version number in the path is the only clue you have as to whether they're are compatible with 3rd party software. I'm still in favor of dropping the rest of the version-numbers, including Evolution's data directory.
As far as i can tell, only evolution is affected these days (gtkhtml has an API version in /usr/share/ included, which should be fine and conform with glib-2.0 an similar). I see currently in evolution: /usr/lib/evolution/3.14/ /usr/include/evolution-3.14/ /usr/libexec/evolution/3.14/ /usr/share/evolution/3.14/ while them all can have dropped the 3.14 from the names/folders.
Created commit b05e2a5 in evo master (3.13.6+) [1] [1] https://git.gnome.org/browse/evolution/commit/?id=b05e2a5