Debian packages for ZeroC Ice

[fmoya]

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.

[n2503v]

Hi Francisco,

Many thanks for maintaining the Debian packages. We use Ice on multiple machines (robots) and using packages save a lot of time. For beginners it also removes a certain psychological barrier associated with using something "big" like Ice.

Could you give a hint when to expect the 3.3 packages in testing?

I'm considering installing from source (made painful by MCPP) but would much rather wait for the packages if they are not too far off.

Cheers, Alex

[fmoya]

Originally Posted by n2503v

Could you give a hint when to expect the 3.3 packages in testing?

I'm considering installing from source (made painful by MCPP) but would much rather wait for the packages if they are not too far off.

Starting from Ice 3.3 ZeroC changed their release policy. Now there is a single source package. The 3.2 building rules found in Debian packages were merged together into a single set of building rules. Therefore the build dependencies were merged together and it turned out into build dependencies which cannot be met in some architectures (e.g. mono is missing on most architectures). I'm now rewriting the building rules in order to avoid unmet dependencies (separate arch-dep build and arch-indep build). Hopefully it will be released by the end of July.

BTW: MCPP is not a problem now that Debian promoted mcpp 2.7.1 to testing.

Regards,
F. Moya

[n2503v]

thanks for the update.

TW: MCPP is not a problem now that Debian promoted mcpp 2.7.1 to testing.

and thanks for the tip, much easier this way.

alex

[trivian]

Hi,

I'm using the package in testing for mumble-server, and it works great

However.. Could you add static libraries to the dev package? I release static binaries for use on non-updated distributions (like etch), which has too many outdated dependencies that it's possible to do a backport, so at the moment I have to disable ICE for those builds. The availability of static libraries would (hopefully) solve this issue for me.

[bernard]

Hi Thorvald,

The Ice build system does not provide a "build static libraries" option, so I suspect it would be a bit of work to add one for the Debian packages (or any other distribution).

Also, not everybody likes static libraries . See this thread.

Ice overall, and more so the Ice core, does not have many third-party dependencies. Maybe you could just provide the few required shared libraries alongside your Ice shared library?

Cheers,
Bernard

[fmoya]

Originally Posted by trivian

I release static binaries for use on non-updated distributions (like etch), which has too many outdated dependencies that it's possible to do a backport, so at the moment I have to disable ICE for those builds.

Perhaps you should consider tools such as EEE: EEE - Environment Embedding Executable, or ELF STATIFIER MAIN PAGE, or Ermine: Home. But you will need to pay special attention to IceBox services and Ice Plugins.

Regards,
F. Moya

[trivian]

Originally Posted by bernard

The Ice build system does not provide a "build static libraries" option, so I suspect it would be a bit of work to add one for the Debian packages (or any other distribution).

Hi,

I ended up manually compiling Ice 3.3.0, and had to change the build system slightly. I did end up with working static libraries though, and I'm now shipping a fully static binary that works on all the distros I have tested

I kind of doubt it is of genereal interest, but if anybody wants it let me know and I'll make a proper patch of it.

[trivian]

Originally Posted by fmoya

Starting from Ice 3.3 ZeroC changed their release policy. Now there is a single source package. The 3.2 building rules found in Debian packages were merged together into a single set of building rules. Therefore the build dependencies were merged together and it turned out into build dependencies which cannot be met in some architectures (e.g. mono is missing on most architectures). I'm now rewriting the building rules in order to avoid unmet dependencies (separate arch-dep build and arch-indep build). Hopefully it will be released by the end of July.

I see lenny still only has zeroc-ice32. Since lenny is now frozen, is there still a chance to see the 3.3 version in lenny?

[fmoya]

I'm afraid that unless the new package fixes a release critical bug it cannot enter a frozen distribution. For your convenience I made lenny x86 binaries available at the following apt repo:

deb http://arco.esi.uclm.es/~francisco.moya/debian-lenny ./

Add the above line in your /etc/apt/sources.list and run apt-get update before you try to install Ice 3.3.

For architectures other than x86 I'm afraid you will need to compile the package yourself. It shouldn't be that hard. Add my repo to your /etc/apt/sources.list and run:

$ apt-get update
$ apt-get install build-essential cdbs debhelper patchutils libdb4.6++-dev \
   libmcpp-dev libreadline5-dev libexpat1-dev libssl-dev libbz2-dev \
   zlib1g-dev python-all-dev python-support php5-dev ruby1.8-dev \
   ruby1.8 cli-common-dev mono-gmcs libmono2.0-cil pkg-config \
   default-jdk-builddep proguard libdb4.6-java ant ant-optional \
   libjgoodies-forms-java libjgoodies-looks-java
$ apt-get source zeroc-ice
$ cd zeroc-ice-*
$ dpkg-buildpackage -b
$ dpkg -i ../*.deb

You may even build just the sections of Ice you use. For example, instead of dpkg-buildpackage you may issue:

$ fakeroot ./debian/rules binary/cpp

Or even a single package:

$ fakeroot ./debian/rules binary/icegrid-gui

Regards,
F. Moya

[trivian]

Hi,

I plan to package a few PHP/ICE examples with Mumble, and that means including the
ice.slice=/path/to/Murmur.ice
somewhere in the php configuration.

However, if I do that, that profile will be the default for all of PHP, which probably isn't right.

Have you considered adding
ice.profiles=/etc/php.ice.profiles
and an empty php.ice.profiles file, or something along those lines? Then other packages could simply append their named profile to that file.
Perhaps a directory /etc/php.ice is appropriate, with a ice.profiles file and the various .ice files applications want to install.