[Bug 441415] Review Request: wastesedge - Official game package for Adonthell

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: wastesedge - Official game package for Adonthell


https://bugzilla.redhat.com/show_bug.cgi?id=441415





------- Additional Comments From j.w.r.degoede at hhs.nl  2008-06-01 15:17 EST -------
(In reply to comment #7)
> About the icons location, I looked for it so I could have discuss this upstream,
> and I found this in the Freedektop Icon Theme Spec
> (http://standards.freedesktop.org/icon-theme-spec/latest/ar01s03.html):
> > Icons and themes are looked for in a set of directories. By default, apps
> > should look in $HOME/.icons (for backwards compatibility), in
> > $XDG_DATA_DIRS/icons and in /usr/share/pixmaps (in that order).
> 
> Are you sure it has been deprecated ? Do you have another link explaining it so
> I can sell this point upstream for future release ?
> 

Well I don't have a document saying so, but /usr/share/pixmaps is the old way of
installing icons. It does not allow for theming, nor does it allow installing
multiple sizes of an icon in such a way that a using application (like the
gnome/kde/xfce applications menu) can automatically use the correct size
depending upon the size it needs.

With the /usr/share/icons way, if you have a large panel and place a launcher
there you will automatically get the more detailed 32x32 icon, with the
/usr/share/pixmaps way you are stuck to whatever size you've hardcoded in the
.desktop file (as the size now is encoded into the name you've specified in the
.desktop file).

But as said this is a should, so if you feel this is not worth the trouble you
do not have todo this.

> Another question, you said:
> >  mv wastesedge_16x16.xpm /usr/share/icons/hicolor/16x16/apps/wastesedge.xpm
> >  mv wastesedge_32x32.xpm /usr/share/icons/hicolor/32x32/apps/wastesedge.xpm
> 
> So I assume I should do that in a %post section, is that the preferred method
> over simply patching the Makefile so that it installs in the right place ?
> 

Indeed it is not necessary to patch the makefiles, but using things like mv in
%post is a really bad idea, just move the files to the new location in
$RPM_BUILD_ROOT in %install (after calling "make install")

> I corrected the "install -p" point, but you didn't make this remark in my other
> submission. Is there a reason why I should do this in this package and not in
> the other ? Or should I correct it in adonthell too ?

You should correct it in adonthell too, I realised this myself too when making
the remark here, but with adonthell its less important as AFAIK no datafiles are
installed there, only compiled files which will have the time of build as
timestamp anyways, so preserving there timestamp is not really important, but
for autoxxx generated makefiles you should really _always_ specify
INSTALL="install -p"


-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.