Hints for packaging

[pphaneuf]

No description provided.

[pphaneuf]

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 saymake 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

[pphaneuf]

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!

[pphaneuf]

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.