Bug 24 - Makefile does not respect prefix when installing GNOME data
: Makefile does not respect prefix when installing GNOME data
Status: RESOLVED FIXED
: Sylpheed-Claws (GTK1)
Other
: 0.8.8
: PC Linux
: minor
Assigned To:
:
:
:
  Show dependency treegraph
 
Reported: 2003-01-18 02:24 by
Modified: 2003-02-24 12:13 (History)


Attachments
Trivial patch for this problem, although it assumes GNOME location (637 bytes, patch)
2003-01-18 02:27, Tim Jackson
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-01-18 02:24:44
The Makefile does not respect the prefix given when installing the GNOME data
(pixmap and desktop files).

This is particularly significant if you are building an RPM as an unprivileged
user, since "make install" will try to put sylpheed.png/sylpheed.desktop in
/usr/share/... instead of [tempdir]/usr/share/... .

Specifically, pixmapdir and gnomapdir are the problematic variables.
------- Comment #1 From 2003-01-18 02:27:05 -------
Created an attachment (id=8) [details]
Trivial patch for this problem, although it assumes GNOME location

This puts the files discussed into PREFIX/share/... which is better than
nothing, should suit most systems, and allows RPMs to be built as non-root,
though there's probably a better way of doing this.
------- Comment #2 From 2003-01-18 03:06:13 -------
<i>though there's probably a better way of doing this</i> 
Yes. Compile from source? Doesn't imply building from RPMs that you need to be 
root? 
The whole idea of this was to put the .desktop and .png in the gnome global dir. 
Or am I missing something? 
------- Comment #3 From 2003-01-18 03:23:07 -------
I think you're missing the point.

*Building* an RPM and *installing* an RPM are not the same thing.

Here, I'm talking about *building* as an RPM, which is the act of compiling from
source and packaging into an RPM, which you do with the help of a 'spec' file.
You can see the spec file I'm using at http://www.timj.co.uk/linux/rpms.php .

When you build an RPM from source, you don't install the files directly into the
system tree. Rather, you use a temporary "BuildRoot" and install everything into
there (using a prefix). Then, you package the files in there into an RPM
package, which is then installed as root, and the files are put into the 'real'
filesystem. So, typically, PREFIX might be /var/tmp/blahfoo

The problem here is that the Makefile ignores PREFIX when installing the GNOME
stuff - instead of putting it in /var/tmp/blahfoo/usr/share/..., it tries to put
it directly into /usr/share/...

This is a Bad Thing, not only for building RPMs, but for anyone who wants a
non-standard prefix. Sylpheed (unlike some other programs) is "well-behaved"
other than for these files - it fully respects the given prefix. Ignoring the
prefix for these two files is definitely an anomaly/bad behaviour.

This also illustrates the importance (aside from normal security issues) of
building RPMs as non-root, as it shows up problems like this. If I'd built it as
root, the png and desktop files would have been installed directly into my
system tree - even though I hadn't installed the RPM. Very bad.
------- Comment #4 From 2003-01-18 03:34:35 -------
|This also illustrates the importance (aside from normal security issues) of 
|building RPMs as non-root, as it shows up problems like this.  
 
Explain "normal security issues" when building as non-root. 
------- Comment #5 From 2003-01-18 06:15:18 -------
Debian hast the same problem when building packages that do not respect the
prefix.  The package system requires that all files are installed in the prefix
directory to create the package. Doing this with fakeroot allows to build
packages without root previleges.
------- Comment #6 From 2003-01-19 03:28:16 -------
The patch will not work, Makefile.in is an autogenerated file.
------- Comment #7 From 2003-01-19 04:45:58 -------
Indeed: file should be Makefile.am 
 
Why not have one of our distro liaisons (Kov? Didge?) donate their distro's 
Makefile.am?  
 
------- Comment #8 From 2003-01-19 05:37:37 -------
In my opinion this is a problem in the gnome-config script. It can only output
the current path that is used by gnome. The gtk-config script, for example,
allows you to specify the prefix and it then appends the required paths to the
prefix. A real fix would have to get `gnome-config --datadir`, then remove the
`gnome-config --prefix` and replace it with the configure scripts prefix. The
gnome datadir does not have to be {prefix}/share. The purpose of gnome-config is
to find out the required subdir, but it not flexible enough.
------- Comment #9 From 2003-01-19 14:18:37 -------
I have not yet noticed this problem, because I simply force the Gnome stuff in,
as  the autobuilders for archs other than i386 would only install them if gnome
devel stuff was installed. Making them a Build-Dependency for sylpheed-claws
just to install a .desktop is insane.

But here is a very simple patch that should work:

diff -urN Makefile.am.old Makefile.am
--- Makefile.am.old    2003-01-18 00:28:14.000000000 -0200
+++ Makefile.am    2003-01-18 00:28:17.000000000 -0200
@@ -17,17 +17,10 @@
        sylpheed-64x64.png \
        autogen.sh
                                                                                
 if SYLPHEED_GNOME
-pixmapdir=$(gnomedir)/share/pixmaps
+pixmapdir=$(prefix)/share/pixmaps
 pixmap_DATA=sylpheed.png
-gnomapdir=$(gnomedir)/share/gnome/apps/Internet
+gnomapdir=$(prefix)/share/gnome/apps/Internet
 gnomap_DATA=sylpheed.desktop
 else
 pixmapdir=
 pixmap_DATA=
 gnomapdir=
 gnomap_DATA=
 endif
                                                                                
 BZIP2_ENV =
  
-------------------------------------------------------------------------------

It was hand-edited from my own patch to make GNOME always detected. I will not
send a file attached to the bug, you got the idea =D.

Hope it helps.
------- Comment #10 From 2003-02-24 12:13:43 -------
I now changed the configure script to remove `gnome-config --prefix` from
`gnome-config --datadir` and add ${prefix} instead. In my opinion this should be
the best solution and will also work if the gnome data is not installed in
${prefix}/share