When release draws near, more and more difficult decisions arise. Like: should I still upgrade the package to a newer upstream version?

Enigma is a great puzzle game, very similar to Oxyd. Back when still using my trusty old Atari ST, I was a fan of oxyd.

Debian unstable currenlty has Enigma 0.92, the latest released version. Experimental contains recent SVN snapshots of the game.

Version 0.92 was released in 2005, and there have been huge improvements to Enigma in the mean time, including a new level form (XML-based, while the levels used to be lua scripts), a reorganization of the levels into level packs with increasing difficulty, tons of new levels and graphics for 1024x768.

While the new versions are running quite stable, and a new release is expected for end of the year, it will probably be not on time for etch.

So should I upload a SVN checkout to unstable (and eventuall etch) - I didn't receive bug reports for the experimental version so far, and enigma has shown before to be of high code quality - or stay with the latest released version?

"Life" would be easier if enigma released a new version just in time for etch. ;-) Just kidding.

I'd certainly prefer the new version; and while there are some known issues with it (a conflict between C++ exception handling and lua when nesting), these might as well apply to the current version. (For example, the screensaver tends to turn on while playing enigma, but upstream said this is actually a SDL issue, and it should apply to both versions)

Maybe some people can test the enigma package from experimental and send me feedback reports. But don't blame me if you lose valueable hours of sleeping time by playing enigma. It can be quite addictive.

In #selinux, we helped a user today to get some SELinux working on Ubuntu.

I had posted before that I expect Ubuntu to be rather close to Debian in terms of SELinux support. This is not true.

Ubuntu ships rather old versions of the toolchain and SELinux libraries. I doubt that you can use the reference policy with this toolchain; the selinux policy shipped by Ubuntu is no longer supported.

Still these would mean that SELinux on Ubuntu would be in the same shape as it is on Gentoo. If it weren't for this critical issue:

sysvinit (2.86.ds1-6ubuntu8) dapper; urgency=low
 
  * Disable SElinux again, nobody gave me a patch to fix the annoying
    message.
 
 -- Scott James Remnant <scott@ubuntu.com>  Fri,  3 Feb 2006 17:54:55 +0000

Init. The process supposed to load the policy at boot, is not SELinux enabled on Ubuntu. At least the version in hoary. And edgy comes with upstart, which doesn't have SELinux support either, AFAIK.

So to use SELinux on Ubuntu you'll have to build your own sysvinit (sysvinit from edgy might do the job). Or add SELinux support to upstart.

The horror of providing full SELinux support out of the box are install scripts.

Installing files of a package is rather easy. Install them, relabel them. This can be added to the package manager. (And I believe dpkg already does that).

However, package install scripts are becoming more and more complex, and they aren't SELinux aware. And there is a lot of stuff that can go wrong here.

For example, a package might want to generate a configuration file for the service you just installed. If this configuration file is to have the same context as the directory containing the configuration file, there won't be a problem - but if it's to have a different context, the generated file will be incorrectly labeled.

I see two basic solutions to this:

• require by policy all package install scripts to register all files they created (and the registration application could then take care of the appropriate file labeling) - but this will take a long time to be adopted by all packages
• monitor package install scripts for file creation, and relabel them automatically. However, many install scripts will also start the service the package contains; monitoring shouldn't extend to them, so I doubt this will actually work, and still problems might arise to delays in relabeling

Any other smart solution for these problems?

Sometimes I wish we could do without turing-complete postinst scripts...