Hints for packaging

[GoogleCodeExporter]

Wow, rc5, final version is getting closer and closer, hooray! ;)

Some hints to make it much easier for Linux distributions to create quadra
packages, as well as to make it easy for users to install it on their Linux
boxes. I think it's better to get these before release, than to create
packages for 1 distro out of hundreds after the release.

It's a huge help if quadra can install to a different root where the files
can be collected to be packaged together. (The version installed there does
not need to be able to run from there.) Also it would be nice if I didn't
have to override tons of Makefile variables (bindir, datagamesdir, datadir)
to do this. The tipical convention is to use the variable called DESTDIR. A
small change in the .mk files (e.g. ``$(INSTALL_PROGRAM) quadra
$(DESTDIR)$(bindir)/quadra'' etc. and similar to the mkdir's for
installdirs target) doesn't make a difference if DESTDIR is unset, but
makes packaging a whole lot easier: you can say ``make DESTDIR=/tmp/xyz
install'' as a simple non-root user and then just pack up the files found
under /tmp/xyz, that's it, the package is ready.

Seamless integration with desktop environment menus would be great.
rules.mk has some FIXME comment with pretty obsolete pathnames. For ages
now, Gnome & KDE & other freedesktop-friendly environments look for the
.desktop files under ${datadir}/applications, e.g. /usr/share/applications,
/usr/local/share/applications, whatever...

A Categories= line should be added, it's a semicolon-separated and
semicolon-terminated list of categories that eventually specify the place
in the menu. I think Categories=Game;BlocksGame; is a quite good choice. (I
just looked up gnometris's entry on my computer.)

Comment= might be shown by the desktop as a balloon help for example, or
shown in parantheses, so having Name=Quadra and then Comment=Quadra is
silly, Comment should either be removed or changed to a real comment, e.g.
"Multi-player tetris game". Maybe Encoding=UTF-8 and Comment[fr]=..... and
such for i18n, really not important especially if the game is English only
(is it?)

The current .desktop file has hardcoded pathnames. Either you have to
postprocess this file according to the configure parameters, or simpler,
just use relative names, e.g. "Exec=quadra", "Icon=quadra".

About the icon: the trendy convention is to use png or even better svg (xpm
is pretty old-fashioned, partially due to the lack of alpha support - you
do want the background to be transparent, don't you? ;)), and put them to
/usr/share/icons/hicolor/SIZE/apps, whereas size is either XXxXX and you
put pngs here, or "scalable" is the place for svg files. That's why usually
the filename extension is not specified in the Icon= field of the desktop
file, the best one is picked up by the desktop environment. 'hicolor' is a
stupid name meaning the default, so that graphical themes can provide
alternative versions. E.g. if you create icons that match the look of Tango
then you'd put them into the Tango directory instead, so users having this
theme will get this icon. But still there should be a fallback default in
the 'hicolor' directory.

cheers

Original issue reported on code.google.com by egm...@gmail.com on 23 Jun 2008 at 7:51

[GoogleCodeExporter]

I think we already had support for setting a root, used for the RPM package, 
but I'll
check. On Debian, I don't think it's as useful, since there is fakeroot, but 
it's
generally handy, that's true.

I keep meaning to make Freedesktop-style .desktop files, just never got around 
to it!

You should see the grief the XPM icon gave me! GCC now gives warnings (I often
compile with -Werror) on non-const char* literals, and the damned thing is 
basically
built out of them! They are rather old school, I agree, but that's the way 
things
used to be done at the time of the previous release. ;-)

I'll check to see what we could do from your list, do as many as possible, and 
file
issues for the rest (I don't think any of this is *CRITICAL*, it just makes it 
easier
to package)... There's already a few, like issue #24.

Thanks!

Original comment by pphaneuf on 24 Jun 2008 at 4:39

• Changed state: Accepted
• Added labels: Type-Enhancement, Maintainability, OpSys-Linux
• Removed labels: Type-Defect

[GoogleCodeExporter]

Oh, something specific to Quadra that we should really remember to do when 
packaging
1.2.0 and later for distributions would be to use the --disable-version-check
configure flag!

This should be used for packaging where the user is not going to be the one 
deciding
when to update (for example, on Debian or Ubuntu). If we make an RPM package 
that
people download and install themselves, then it would make sense not to put in 
that
option.

Original comment by pphaneuf on 25 Jun 2008 at 12:51