25 January 2008

I've got an upload of gpe-tetris pending - see 462306 - to provide a smaller version of the popular falling blocks game for embedded devices. One or two things crop up from this package:

1. popcon - a lot of maintainers put a lot of store by popcon results but the popularity-contest package is perl and perl is not available in Emdebian (it is thrown out along with "Essential: yes" for space reasons). Writing a replacement for popcon may not be particularly sensible either because embedded devices, although often left running for long periods in a "low power" mode, often have rare and intermittent access to any form of internet connection. This could easily result in maintainers thinking that because a package has few (or even zero) popcon figures, it is not used. On the contrary, the package could simply be used on devices that either do not support perl (Emdebian) or which do not have the ability to file popcon reports despite being able to support perl. (With the probability that GPEPhone will be added to the GPE support already in Debian, users may not wish to have popcon "phoning home" because it would likely cost real money to do so - even if a C version of popcon was written.) So I'm posting this here so that I can refer back to this post if queries arise later on.
   


2. GPE apps on Debian - gpe-tetris is inherently designed for small devices with small screens and relatively slow processors, just like the majority of GPE. gpe-tetris is also designed to be usable on a handheld device where the lack of a normal keyboard can make game play awkward. As a result, playing gpe-tetris on an average Debian box is likely to appear trivially easy and the "progression" between levels would appear very slow in comparison with the tetris available in GNOME or KDE. This is deliberate and is expressly intended to allow the game to be playable on embedded hardware that has fiddly little keys. (I'll be adding this to the manpage and a brief summary of this to debian/control.) This does give the opportunity for a little sleight-of-hand such that a device could be provided with a highscore file created on a much more powerful device and so preventing any new highscores being set, but please don't do that - play nicely!
   


3. small apps != bad code - Yes, lots of GPE packages are very small, some were clearly written originally as "demos" or during the process of learning how to write larger packages. This does not necessarily mean the packages contain bad code. I will feed back sensible patches to upstream to resolve flaws in the code but please do not think ill of the packages merely because the source code looks "trivial" compared to a GNOME package.
   


4. dpkg-shlibdeps - one issue that I must begin to track after Fosdem will be to aggregate the "foo should not be linked against" messages from dpkg-shlibdeps in GPE packages and try to build a complete picture, in case there is a real possibility of completely dropping some packages that always seem to appear in that list due to the pkg-config --libs gtk+-2.0 listing. If so, I'll begin discussions with upstream about manually specifying the GTK_LIBS variable whilst retaining the PKG_CHECK_MODULES macro that ensures that the -dev package is available in the cross-building environment. This is likely to be some form of database-query mechanism - feeding data in from grepping the build logs, building a query from the list of packages to be used for a specific Emdebian root filesystem (machine/variant specific) and then spitting out whether particular package sets can have particular targets removed. If anyone fancies working on that already, the Debian version of the information is already available via the buildd network and the Emdebian cross-build results will not differ greatly from those at this stage.
   

Other uploads include updates of libgpeschedule, gpe-calendar and gpe-clock if gpe-announce makes it through NEW as expected. Updates for emdebian-tools and apt-cross and likely new releases for QOF, gpe-expenses and pilot-qof.
debcheckout compliance
In other developments, I've worked out how to specify Vcs-Cvs correctly such that debcheckout can find the repository data correctly. Sadly, vim syntax highlighting does not help with the CVS version but the CVS syntax is:

Vcs-Browser: http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-view/?cvsroot=dpkg-view

Vcs-Cvs: :pserver:anonymous@cvs.alioth.debian.org:/cvsroot/dpkg-view dpkg-view

Note the colon prefix to pserver and the space between the repository login location and the module name. Remember to omit the "-d" - debcheckout will add that for you (and won't check to see if you have already specified it).