Renaming a Debian package

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:

  • Create a new package with the new name which will get uploaded to the NEW queue. This package Replaces, Provides and Conflicts with the old package: Replaces: oldPackage Provides: oldPackage Conflicts: oldPackage (<< firstVersionOfNewPackage) Replaces and Conflicts are obvious, and Provides assures that other packages which depend on the old package still can satisfy their dependency.
  • Once the package has moved from the NEW queue to unstable, create a new revision of the old package which serves as dummy package. It does not install any files (except the mandatory ones in /usr/share/doc) and depends on the new package.
  • Finally, after the current testing distribution has been released, file a bug asking ftpmaster to remove the old, dummy package.
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 … [UPDATE] 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: Package: oldpackage Architecture: any Depends: newpackage

The difference in x86_64 linux distributions

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.

The mobile network

When I took my laptop to different locations within our company building I always had to reconfigure the network, or shut it down and boot it back up at the new location. Then, I found this little daemon at which waits for link down and link up status changes on a network device and can execute any actions on these events. On Debian, a simple “apt-get install ifplugd” was sufficient so that the laptop now reconfigures the network device when the link has gone down and comes up again.