After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 341802 - Make Evolution installed directories names without version
Make Evolution installed directories names without version
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
2.30.x (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2006-05-15 06:08 UTC by Irene Huang
Modified: 2014-09-08 17:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for evolution-data-server (2.02 KB, patch)
2006-05-17 08:23 UTC, Boby Wang
needs-work Details | Review
patch for gtkhtml (2.75 KB, patch)
2006-05-17 08:24 UTC, Boby Wang
rejected Details | Review

Description Irene Huang 2006-05-15 06:08:47 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:
Comment 1 Harish Krishnaswamy 2006-05-15 08:24:38 UTC
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.  
Comment 2 Boby Wang 2006-05-17 08:23:24 UTC
Created attachment 65646 [details] [review]
patch for evolution-data-server
Comment 3 Boby Wang 2006-05-17 08:24:35 UTC
Created attachment 65647 [details] [review]
patch for gtkhtml
Comment 4 Karsten Bräckelmann 2006-08-04 16:55:40 UTC
*poke*  Will this be done in time? Also, does this seriously block GNOME 2.16?
Comment 5 Harish Krishnaswamy 2006-08-05 05:18:10 UTC
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.
Comment 6 Harish Krishnaswamy 2006-08-07 11:02:34 UTC
Looks good to me. 
Srag, can you test this independently and confirm too..TIA
Comment 7 Harish Krishnaswamy 2006-08-07 11:16:07 UTC
er..this seems to be incomplete wrt idl and includes..
Comment 8 André Klapper 2006-08-22 23:21:50 UTC
postponing to an early stage of 2.9.
Comment 9 Matthew Barnes 2006-09-17 03:09:20 UTC
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.
Comment 10 Matthew Barnes 2008-03-11 00:32:06 UTC
Bumping version to a stable release.
Comment 11 Matthew Barnes 2009-08-03 11:40:07 UTC
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.
Comment 12 Matthew Barnes 2009-11-19 22:22:23 UTC
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.
Comment 13 Milan Crha 2014-09-08 10:50:45 UTC
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.
Comment 14 Milan Crha 2014-09-08 17:22:49 UTC
Created commit b05e2a5 in evo master (3.13.6+) [1]

[1] https://git.gnome.org/browse/evolution/commit/?id=b05e2a5