Issue 104001 - Dot desktop files shouldn't be created with relative links.
Summary: Dot desktop files shouldn't be created with relative links.
Status: CONFIRMED
Alias: None
Product: Installation
Classification: Application
Component: code (show other issues)
Version: OOo 3.1
Hardware: Sun Solaris
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-04 15:58 UTC by richburridge
Modified: 2017-05-20 11:33 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description richburridge 2009-08-04 15:58:39 UTC
If I've filed this under the wrong component, please adjust accordingly.
I'm sure I've got the version number wrong. This is for OOo v3.1.0.
Where is the version entry for that?

This bug has been opened to get the attention of the OpenOffice developers.

See also OpenSolaris bug
http://defect.opensolaris.org/bz/show_bug.cgi?id=6719

The description from that bug is included below.
--

When moving OpenOffice gnome-panel icon to desktop, a copy of the desktop file
is made. But this one is a link. The issue is that the link is a relative link
and base from /usr/share/applications directory. If the home directory is not
on level 2, the link is not more valide. Please change the link to an absolute
position or push the real desktop file in /usr/share/applications.
--

There is further commentary in the openSolaris bug. Please read it all to
get the full picture.

Thanks.
Comment 1 floeff+ooo 2009-08-04 16:12:43 UTC
Most probably not a distribution issue. Maybe framework?
Comment 2 Joost Andrae 2009-08-04 16:42:46 UTC
Olaf, please have a look at this
Comment 3 Joost Andrae 2009-08-04 16:44:03 UTC
.
Comment 4 Joost Andrae 2009-08-04 16:44:51 UTC
modified version info
Comment 5 Olaf Felka 2009-08-05 12:17:22 UTC
I can't reproduce. I've installed OOo 3.1
(http://download.openoffice.org/index.html) and created the gnome desktop entry
as you have described. The desktop link works and started OOo.
a ihi: Any idea on this issue?
Comment 6 richburridge 2009-08-05 15:55:47 UTC
Steps to reproduce:

1/ Install OpenSolaris 2009.06
2/ Install OpenOffice 3.1
3/ Left click on the Applications menu in the top left of the screen.
4/ Left click on the Office menu item.
5/ Hover the mouse over one of the OpenOffice menu items 
   (say, "OpenOffice 3.1 Writer").
6/ Hold the left mouse button down and drag the menu item onto the
   desktop background.

You will have created a broken link.

If you try to double click on it to launch the application, 
you will get an error popup displayed.

That's the problem.
Comment 7 Olaf Felka 2009-08-05 16:06:22 UTC
I've tried it with the context menu which works fine. 
@ ihi: As described, dragging isn't working.
Comment 8 mdxonefour 2009-08-05 16:11:26 UTC
MD->OF: I assume the OOo 3.1 from the OSOL Repository was used. Thats a vanilla
OOo 3.1 converted into IPS.
Comment 9 ivo.hinkelmann 2009-08-05 16:54:05 UTC
ok ... the problem here is that he moves the link out of applications directory
to a misc location:

/usr/share/applications$ ls -l openoffice.org3-base.desktop
lrwxrwxrwx 1 root root 51 2009-05-31 10:50 openoffice.org3-base.desktop ->
../../../opt/openoffice.org3/share/xdg/base.desktop

of cause after moving the link the relative link points to nowhere.

Rich the problem is that we can not use absolute paths as we don't know them!
All the stuff can be installed into /usr/ & /opt or for example into
/my/own/usr/ & /my/own/opt
Comment 10 richburridge 2009-08-05 17:43:53 UTC
For OpenSolaris, the packages that your provide should
just put the various .desktop files under /usr/share/applications.
That's all that's required.

Thanks.
Comment 11 mattman 2009-08-05 17:55:15 UTC
ihi, just want to clarify what you are saying.

At install time of OpenOffice you don't know where it's going to be installed ?
but you do know the exact directory depth it will be installed into ? thus the
specifying of ../../../ in the desktop file that is installed to
/usr/share/applications.

This is really broken from the GNOME desktop perspective. Maybe you can amend your
installation to have a post install of some sort that will dynamically set the
Exec path of the installed desktop file once it knows where that location is
going to be ?
Comment 12 mdxonefour 2009-08-05 18:02:05 UTC
We don't deliver extra packages for OpenSolaris. There is one Solaris
installation set which should work on Solaris and OpenSolaris. Please keep this
in mind when solving it. I don't like to see any new OpenSolaris specific packages.
Comment 13 richburridge 2009-08-05 18:02:12 UTC
"Maybe you can amend your installation to have a post install of 
 some sort that will dynamically set the Exec path of the installed 
 desktop file once it knows where that location is going to be ?"

I'm not sure this is going to help for OpenSolaris IPS packaging,
as it ignores all scripting such as the SVR4 .../install/postinstall
files.

Or were you thinking of something different?
Comment 14 mattman 2009-08-05 18:17:16 UTC
I know IPS dosen't have any equivalent of SVR4 postinstall, I'm just trying to
get a grasp on what this install actually does.

Guess I'm kind of confused as ihi mentions that they do not know where OO is
going to be installed. So the desktop file must be amended during install to
have the correct number of ../../ etc., if this is the case then why can it not have
an absolute path put in here ?

If installing from IPS or SVR4, surely the installation points are hard defined
within each package type ? and therefore you do know where the binaries are
going to be installed ?
Comment 15 ivo.hinkelmann 2009-08-05 18:53:09 UTC
I do not modifiy the desktop files nor pkgmap's links during installation ...

the pkgmap looks like this:
1 s none
usr/share/applications/openoffice.org3-writer.desktop=../../../opt/openoffice.org3/share/xdg/writer.desktop
Comment 16 ivo.hinkelmann 2009-08-06 11:00:06 UTC
something somebody could test if the tryexec field in the desktop files now work
on current solaris installation. If it works we can move the desktop files into
the desktop integration packet and no longer ship them in the application
packages. But on older Solaris versions this don't work ...
Comment 17 Olaf Felka 2009-08-06 11:13:47 UTC
Older Solaris versions means what?
Comment 18 ivo.hinkelmann 2009-08-06 11:23:01 UTC
Solaris 8 for sure ... for 9 + 10 I have to test, I don't know right now
Comment 19 Marcus 2017-05-20 11:33:15 UTC
Reset assigne to the default "issues@openoffice.apache.org".