Message printed to the log:

"(evolution-2.10:5401): Bonobo-WARNING **: Error: 'Unable to find help paths /usr/share/gnome/help/evolution-2.10 or /usr/share/gnome/help/evolution-2.10.Please check your installation'"

In Ubuntu: https://bugs.launchpad.net/distros/ubuntu/+source/evolution/+bug/76004

Still happening in 2.9.91.

*** Bug 399299 has been marked as a duplicate of this bug. ***

I can confirm this on Mandriva Cooker with evolution 2.10.0.

One thing that differs with the previous version is that evolution.xml
installed under /usr/share/gnome/help/evolution, not
/usr/share/gnome/help/evolution-2.10. So yelp can't find it.

I looked into source tree and found that Makefile.am under evolution/help/C
doesn't exist again. I don't know why those files removed.

Evolution is trying to open evolution-2.10/evolution-2.10.xml but the installed help document is evolution/evolution.xml, so we can either rename the help file and directory to the versioned name or make evolution look for the unversioned one.

Created attachment 84951 [details] [review]
remove version from all gnome help calls

This patch should be apply before 2.18.1, please.

Created attachment 85709 [details] [review]
better patch

previous patch was not fixing all help calls in evolution.
New patch is changing the other way around (evolution calls evolution-BASE_VERSION help file) but it requires changes in the source file from evolution.xml to evolution-1.10.xml (same for .omf file), which isn't very clean either. I'm not sure it could be done at install time using local-install makefile target.

Frederic, I see compilation errors with your patch.

/usr/bin/install -c -m 644 ./C/evolution-2.10.xml /home/sragavan/opt/gnome218/share/gnome/help/evolution-2.10/C/evolution-2.10.xml
/usr/bin/install: cannot stat `./C/evolution-2.10.xml': No such file or directory
/usr/bin/install -c -m 644 ./en_GB/evolution-2.10.xml /home/sragavan/opt/gnome218/share/gnome/help/evolution-2.10/en_GB/evolution-2.10.xml
/usr/bin/install: cannot stat `./en_GB/evolution-2.10.xml': No such file or directory
/usr/bin/install -c -m 644 ./es/evolution-2.10.xml /home/sragavan/opt/gnome218/share/gnome/help/evolution-2.10/es/evolution-2.10.xml
/usr/bin/install: cannot stat `./es/evolution-2.10.xml': No such file or directory
/usr/bin/install -c -m 644 ./sv/evolution-2.10.xml /home/sragavan/opt/gnome218/share/gnome/help/evolution-2.10/sv/evolution-2.10.xml
/usr/bin/install: cannot stat `./sv/evolution-2.10.xml': No such file or directory
make[2]: *** [install-doc-docs] Error 1

IMHO, the patch from Götz is better. If it isn't complete, we should find the missing references.
I don't see the point in adding the version number to the xml help file.

Claude, I dont think changing the code would be the clean approach. The xml file name change should be ideal IMHO. 

I'm approving the DOC_MODULE patch based on comment #13.

Please commit to Subversion trunk and the gnome-2-18 branch.

Hmm, I think I was a bit hasty.  I don't like the idea of renaming xml and omf files for each new release.  Withdrawing my approval until I can think this over some more.

Frederic, can you clarify which help call were not working with the original patch, as you mentioned in comment #10?

Created attachment 86323 [details] [review]
Revised patch

I found the magic Bonobo call in shell/e-shell-window.c:

    bonobo_ui_util_set_ui (priv->ui_component,
                           PREFIX,
                           xmlfile,
                           "evolution-" BASE_VERSION, NULL);

Removing BASE_VERSION and the hyphen from the 'app_name' argument fixes the
Help -> Contents menu item.  This, combined with the original patch from
Götz Waschk, makes launching help work again throughout Evolution.

Matthew, I still prefer to restore the old way of representing the xml rather than fixing the code to adapt to this. App name is still evolution-BASE_VERSION. The patch just works around the core issue. 

IIRC there were multiple requests to remove the BASE_VERSION from the evolution binary itself (specially from the panel hackers). If we take that together then the approach seems fine to me. 

I guess I don't understand what you regard as the "core issue".

I'm all for killing off BASE_VERSION in as many places as possible.

(In reply to comment #19)
> I guess I don't understand what you regard as the "core issue".
Meant the xml file with out BASE version and binary with BASEVERSION and the inconsistency.
> 
> I'm all for killing off BASE_VERSION in as many places as possible.
Me too. Lets fix it all instead of just one place :)

> 

I can confirm this bug with 2.10.0 under SLES10.

Created attachment 88001 [details] [review]
Patch

This is not a final solution. It should solve the issue at makefile level and leave the sitation to what it was before GDU migration. We need to take up dropping the version altogether.

Srini: how strict is the dependency between the app name and the name of the help file. If there is no strict dependency, I don't see the point in temporarily going back to versioned help file.

Debian will apply Matthew's patch for the already released versions (2.10.1), since Srini's patch breaks. To make Srini's patch work, at least the file names in all locales (not just C) must be renamed or copied like in his patch. In addition, the .omf.in file must be renamed. All that hassle is not worth it in already released versions.

Why not just try to go for unversioned appname? Maybe that's feasible within the 2.12 cycle?

Definitely possible for 2.12 cycle. I dont remember the bug number, but I remember reviewing a similiar patch for that. (Directory/version) It wasn't complete. 

Im fine for pushing Matthew's patch for 2.10.x but I want this to be solved in the right way for 2.12.

*** Bug 420950 has been marked as a duplicate of this bug. ***

*** Bug 438291 has been marked as a duplicate of this bug. ***

*** Bug 438712 has been marked as a duplicate of this bug. ***

adding to the todo for tonight :)

nuking BASE_VERSION requires a "lot" of work in Makefile.am and some file moves (just to remove useless rules in makefiles). I've started this work alongside some cleaning in the Makefile.am so clear some linking warnings (plugin folder for example).

The question I had in mind was, do we want to nuke BASE_VERSION for conduits (probably yes) and for OAFIDs (don't know) ?

This will probably result in a biggish patch updating makefile.am to automake 1.9.
FTR, I've been building evo, e-d-s and gtkhtml with automake-1.10 for a month and  it works already, the above remark will probably just reduce whining about deprecated use of some variables and stuff like that.

I'd like to know if this will be a problem for integration into the trunk ?

(In reply to comment #29)
> nuking BASE_VERSION requires a "lot" of work in Makefile.am and some file moves
> (just to remove useless rules in makefiles). I've started this work alongside
> some cleaning in the Makefile.am so clear some linking warnings (plugin folder
> for example).

Great.

> 
> The question I had in mind was, do we want to nuke BASE_VERSION for conduits
> (probably yes) and for OAFIDs (don't know) ?

Im not sure. We should maintain that. We are looking at just version removal from files. 

> 
> This will probably result in a biggish patch updating makefile.am to automake
> 1.9.
> FTR, I've been building evo, e-d-s and gtkhtml with automake-1.10 for a month
> and  it works already, the above remark will probably just reduce whining about
> deprecated use of some variables and stuff like that.
> 
> I'd like to know if this will be a problem for integration into the trunk ?
> 

I dont know/see if there will be any problems  with automake-1.10. 

*** Bug 439616 has been marked as a duplicate of this bug. ***

Srini asked me to commit the patch in comment #17 to the gnome-2-18 branch.

Revision 33578.

Created attachment 88898 [details] [review]
evolution-base_version-removal.patch

This patch contains (hopefuly) all necessary Makefile.am changes to remove base version from filenames. It has a little more than that (some changes wrt linking) but these other changes shouldn't hurt. I requires that the patch applied to stable be applied to trunk as well so help will open :)

I've been running this for half a day now and I'm quite confident that the other changes will not break evo like hell but if you are not so sure, feel free to disregard them. I'll resubmit work for makefile's in another bug.

forgot to add that the way I did the changes implies that some files have to be moved (.in.in to .in). Here is the status of my copy of the tree :

$ svn st -q |egrep "A"
A  +   addressbook/gui/component/GNOME_Evolution_Addressbook.server.in
A  +   addressbook/gui/component/apps_evolution_addressbook.schemas.in
A  +   shell/apps_evolution_shell.schemas.in
A  +   shell/GNOME_Evolution_Test.server.in
A  +   shell/GNOME_Evolution_Shell.server.in
A  +   plugins/bogo-junk-plugin/bogo-junk-plugin.schemas.in
A  +   plugins/default-mailer/apps-evolution-mail-prompts-checkdefault.schemas.in
A  +   plugins/mail-notification/apps-evolution-mail-notification.schemas.in
A  +   mail/GNOME_Evolution_Mail.server.in
A  +   mail/evolution-mail.schemas.in
A  +   calendar/gui/apps_evolution_calendar.schemas.in
A  +   calendar/gui/GNOME_Evolution_Calendar.server.in

ok, after checking if everything was fine on a fresh svn checkout with make distcheck, it appears some of the change to SMIME part of the Makefile are not so unharmful as I thought. I have yet to find out why and I will produce a new patch ASAP (unless somebody else has the time to do it :)), but for now I need some sleep.

Created attachment 89064 [details] [review]
evolution-base_version-removal-v2.patch

This patch is a stripped down/reworked version of the preceding patch.

It contains :
 - cosmetic fixes (whitespaces, tabs)
 - the real stuff (tm)

You'll need to svn move the following schemas (from .in.in to .in) :
 addressbook/gui/component/apps_evolution_addressbook.schemas.in.in
 shell/apps_evolution_shell.schemas.in.in
 plugins/bogo-junk-plugin/bogo-junk-plugin.schemas.in.in
 plugins/default-mailer/apps-evolution-mail-prompts-checkdefault.schemas.in.in
 plugins/mail-notification/apps-evolution-mail-notification.schemas.in.in
 mail/evolution-mail.schemas.in.in
 calendar/gui/apps_evolution_calendar.schemas.in.in

I couldn't test this fix since I need to clean up my system from the previous one but it passes make distcheck.

Created attachment 89070 [details] [review]
evolution-base_version-removal-missing.patch

hehe, thanks srag for noticing this.

This patch replaces the part applying on shell/Makefile.am and should just generate evolution instead of evolution-$(BASE_VERSION). The second part is the necessary change to the .desktop file.

I will review this tonight and get that in for 2.11.3. Thanks Gilles for your awesome work!

Gilles, I think he .pc files aren't installed with this patch.

Created attachment 89127 [details] [review]
Updated patch

Created attachment 89128 [details] [review]
Exchange patch to pick the right evolution

These two patches work perfectly. I didn't see any issues while reviewing. But still, I would prefer to get a one more round of review on this.

Matthew?

Committed.

Created attachment 89659 [details] [review]
evolution-mail-makefile.am.patch

Without this patch, evolution wouldn't compile Evolution-Mail-common.c.
I wonder how it was still working :)

Good catch.  Please commit to trunk and stable branch (if necessary).

Also, changing the summary to reflect the expanded scope of this bug.

Patch in comment #44 committed to Subversion trunk (revision 33665).

*** Bug 453442 has been marked as a duplicate of this bug. ***

*** Bug 458758 has been marked as a duplicate of this bug. ***

*** Bug 459842 has been marked as a duplicate of this bug. ***

*** Bug 462638 has been marked as a duplicate of this bug. ***

*** Bug 464227 has been marked as a duplicate of this bug. ***

*** Bug 465456 has been marked as a duplicate of this bug. ***

*** Bug 466568 has been marked as a duplicate of this bug. ***

*** Bug 468108 has been marked as a duplicate of this bug. ***

*** Bug 470373 has been marked as a duplicate of this bug. ***

*** Bug 473117 has been marked as a duplicate of this bug. ***

*** Bug 473538 has been marked as a duplicate of this bug. ***

*** Bug 474631 has been marked as a duplicate of this bug. ***

*** Bug 474442 has been marked as a duplicate of this bug. ***

*** Bug 475656 has been marked as a duplicate of this bug. ***

*** Bug 483482 has been marked as a duplicate of this bug. ***

*** Bug 483960 has been marked as a duplicate of this bug. ***

*** Bug 484971 has been marked as a duplicate of this bug. ***

*** Bug 486040 has been marked as a duplicate of this bug. ***

*** Bug 489465 has been marked as a duplicate of this bug. ***

*** Bug 493616 has been marked as a duplicate of this bug. ***

*** Bug 495222 has been marked as a duplicate of this bug. ***

*** Bug 496807 has been marked as a duplicate of this bug. ***

*** Bug 515483 has been marked as a duplicate of this bug. ***

*** Bug 523360 has been marked as a duplicate of this bug. ***

*** Bug 528700 has been marked as a duplicate of this bug. ***