I confess i'm not happy with the result. Further inspection of the packaging scheme used is pretty scary, actually. The package is extremely far from meeting policy, let alone being aesthetically pleasing.
The proper way to implement this package, i think, would be as an irssi module that would depend on the latest version of irssi, rather than including full irssi sources in the build. This would mean that the silc folks wouldn't need to worry about tracking vulnerabilities in irssi, as long as there was no change to the module API used by silc.
However, i don't understand the build process well enough to do this just yet. I also don't quite understand the relationship between silc-toolkit (in debian, apparently unmaintained with severe policy violations), and silc-client. Perhaps we need to kick silc-toolkit into shape first, and then figure out how to make an irssi-silc (with Provides: silc-client) as a dependency of silc-toolkit and irssi?
Comments are welcome. You can reach me at the e-mail address i used to post about this page on silc-devel.
i've installed and run the sarge packages on a couple machines, and they seem to work for me.
as of Wed, 07 Mar 2007 13:51:09 -0500, i've also built silc-server 1.0.3 against sarge (the *sarge_dkg* packages). I have not tested the sarge packages at all. Please let me know if you try them.