Yesterday, I had a closer look at upstart, a replacement for the sysv init daemon. My goal is to speed up the boot process of my Debian desktop installations, and the two systems which could help with this are upstart and initng. There are packages for upstart in Debian experimental, and installing is quite simple, but besides the upstart package itself it is almost a must to also install the package upstart-compat-sysv, otherwise commands like reboot and shutdown are not available anymore. Also, this package provides a default configuration for the upstart jobs which simply emulates the sysv-init based rc mechanism.
Upstart uses the notation of jobs to define the services to start. Unfortunately the sysv-init emulation simply defines jobs like rc1, rc2 and so on, i.e. one job per run level; then, the old sysv-init scripts are still used to launch the services one after the other. The result is that the boot process still took 31 seconds, exactly the same time it took with the sysv-init system.
I then started to write some jobs to launch services like apache2 and sshd independently from the rc scripts, using upstart event definitions. Creating the scripts themselves is quite easy, but I did not manage to stop the services again through upstart's initctl command line interface: it seems that, since the processes fork, upstart assumes that they are stoped again after they have been launched.
Investigation is ongoing ...
Last week, I fixed my first RC bug: it was caused by the removal of libapr0, which rendered my subcommander package uninstallable. Since there was also a new upstream version available, I combined this with the upload.
Since some weeks, my debian package overview looks messed up. All entries appear twice, and most of my (not yet so many ;) ) packages are missing. It seems that this happened after the upload of libtest-unit-perl, the first package I co-maintain within a group. So, I spent some time today setting up a local qa.debian.org environment and tracking down what goes wrong. I have created a bug report with an attached patch which should fix the issue; I hope that it will be committed sometime soon so that the complete package overview is working again.
Recently, the authors of lincvs decided to rename the software to crossvc. This put me as the current maintainer of the lincvs Debian package into a new situation: How do I rename a Debian package? It turned out that this is indeed not so trivial, especially when a seamless upgrade should be possible with apt-get dist-upgrade. After a short web research, it turned out that the following steps are necessary:
I asked on debian-devel whether this is the correct approach, and it seems to. There is still some discussion ongoing whether the new package can itself provide the dummy binary packages of the old package. This would make the process much simpler ...
It turned out that is indeed possible to skip the step of uploading a new revision of the old package when the new package has left the NEW queue. A source package can own other binary packages which are already in the archive, and takeover ownership once they are uploaded. So, for the seamless upgrade, the new package simply needs to create a new binary version of the old package which depends on the new package:
Most (commercial) linux distributions install their x86_64 version as a mixed environment. This means that the 64 bit libraries are installed in /lib64 and /usr/lib64, while the usual directories /lib and /usr/lib contain 32 bit libraries which are necessary to run 32 bit applications.
Debian, on the other hand, provides a pure x86_64 distribution (the amd64 port), where the 64 bit libraries are installed in /lib and /usr/lib. 32 bit libraries are either installed below /emul (through the ia32-libs package) or in a completely separate chroot environment. The chroot environment has the advantage that it uses the normal i386 packages and can even be updated with "apt-get dist-upgrade" separately from the 64 bit installation.
32 bit applications like OpenOffice run very well in the chroot environment, and even building i386 packages is possible. The only disadvantage is that the chroot environment can take up a significant amount of space.
The real problems arise if you need to install a 64 bit application which uses an installer which is built as 32 bit application. No one does this? Sure. Oracle does.
And they require a mixed installation. There seems currently no way to install the Oracle client on an amd64 debian installation.