I can't maintain libsilc due several reasons: a) the silc upstream targz reflects its soname perfectly, but I disagree to maintain 1) a meta-package referring this one, 2) maintain a package which (strictly in my opinion) has a simple API differing the methodology to the debian one.
b) personal things So I'm gladly give it to anybody who is interested in it. On 14/08/05, Robert McQueen <[EMAIL PROTECTED]> wrote: > clone 273871 -1 > reassign -1 tech-ctte > thanks > (cloning bug to leave RC bug open on libsilc) > > The bug is reasonably self-explanatory - on top of the package itself > being incorrectly named (not reflecting the SONAME), this library does > not increment its version when symbols are added, or change the shlibs > values to ensure the appropriate version is depended on. > > The maintainer has amply demonstrated that he doesn't understand the > issue and has made it exceedingly clear that he doesn't care, and that > it's apparently not a problem because nobody on -devel replied to his > message. > > As indicated by Steve Langasek, this is not a theoretical problem - > previous uploads of silc clients to unstable have broken because they do > not have tight enough dependencies on the version of the library that > they were built against. > > I do not wish to make Gaim depend on this library while it is so poorly > maintained, because it will cause an excess burden of support next time > it breaks. I personally am not interested in silc functionality > otherwise I might've tried to fix it and NMU or hijack the package, but > I do recieve occasional user requests for the silc functionality to be > enabled in Gaim. > > This problem has caused there to be no silc clients whatsoever in the > sarge release, because they are all blocked on this library which will > not migrate to testing until this bug is closed, and the same problem > looks set to happen for etch unless something happens. > > Regards, > Rob > > > -- VWOL Tamas SZERB <[EMAIL PROTECTED]>
