First of all I would like to thank ZeroC for this forum. It will certainly contribute to the community around the ZeroC Ice ecosystem.
I know of many people using Debian based distributions with pristine ZeroC Ice sources without a glitch. Michi Henning himself wrote a message in these forums about that. And this is fine most of the time. But in our lab we currently use a decent variety of architectures (x86, amd64, ppc, arm and in a near future ia64) and we do not like the idea of having a separate development machine for every architecture. Besides I use Ice as a teaching tool for several undergrad courses. A packaging system such as Debian packages relieves users from many maintainment tasks that would otherwise be too cumbersome.
Therefore if you happen to use a debian based distribution or ubuntu based distribution try the packages for ZeroC Ice. If you are not convinced you can always go back to a manual installation.
Debian Policy dictates a lot of rules that choke on the ZeroC installation conventions. I try to respect the original source as much as possible, but a number of patches are currently applied to the Debian packages. I'll try to explain the differences and why they are different.
- Debian source packages should be split in as many binary packages as it makes sense. Unfortunately it makes sense a lot of different packages. In 3.2.1 I made a major reorganization in order to merge some of them. Now ZeroC Ice is decomposed into 24 packages.
- What happens to be most frustrating for Debian users is that ZeroC Ice files are not located in a single directory but in the standard places. For their convenience I added the contents of the upstream config directory to the documentation directory of package ice33-services. This is not ideal but at least they can use the migration scripts and the ZeroC Ice Makefiles.
- Debian supports both 2.4.x and 2.6.x kernels. This means that we must deal with kernels where epoll is not available. One alternative would be to build ZeroC Ice without epoll support but that would impact performance of the typical case. As suggested by Jim Paris I modified the event loop to fall-back to standard poll when epoll is not available. The overhead is negligible. Unfortunately there is a regression in 3.3.0-1 because the upstream code was reorganized and I havenīt had enough time to redo the patch.
- ZeroC relies on manual configuration to determine word size and byte order. Unfortunately this is inconvenient for Debian, which supports dozens of target architectures, some of them with multiple byte orders. What I think it is the right solution is to rely on the GNU C library includes. Of course this is again a Debian specific issue and there is no portable way to guess word size and byte order at compile time. Another way would be to execute a small test program but this is a non-issue for any GNU variant.
- JGoodies Looks was missing from Debian due to its reliance on a non-free Java runtime library. Fortunately Gregor Herrman is now actively maintaining libjgoodies-looks-java for Debian. He removes all of the dependencies on non-standard Java features. In particular he removed the WindowsLookAndFeel because it was built on com.sun.javax.swing.plaf.windows which is not available in GNU ClassPath. Therefore I had to remove the WindowsLookAndFeel from IceGridGUI as well. Fortunately IceGridGUI was designed to also support the PlasticLookAndFeel which is also quite nice.
- I install the JAR files into the standard /usr/share/java directory and a symlink named /usr/share/java/Ice.jar is always pointing to the last version. Perhaps I should install an alternative, but I was just waiting for a clearly defined Java Debian Policy.
- The IceGridGUI application is wrapped into a shell script. You just need to invoke icegrid-gui.
- Debian packages support multiple python versions. Debian package is built with python-support, which automatically takes care of compiling python sources with every installed version of the python interpreter.
- The IcePHP extension is automatically configured to be available as an extension. It is currently installed directly on the extension directory. This is far from ideal since this scheme disallows the simultaneous installation of different versions. I'm just waiting for a clearly defined PHP Debian Policy.
- Debian packages of ZeroC Ice for C# conform fully with the CLI Debian Policy. DLLs are shared among the available CLR implementations and they are properly installed in the GAC of every available runtime.
- While installation directories are completely different to the ZeroC makefiles users should not notice that. Using the -pkg:icecs notation you may build completely portable Makefiles.
- The iceboxnet.exe executable is renamed to include the interface version and wrapped into a shell script. You should just run icebox-3.3.
- Of course I try to track closely the Patches Forum at the ZeroC Ice site and all binary compatible patches are applied as soon as they are released.
- Ruby package uses completely different installation directories but that should be hidden from the user. Currently I only support ruby1.8. The module is currently installed directly on the architecture-dependent directory. This is far from ideal since this scheme disallows the simultaneous installation of different versions. I'm just waiting for a clearly defined Ruby Debian Policy.
We are also involved in some personal projects and research projects which use Ice in some way. I will try to send a description shortly.

Reply With Quote

