This is a copy of the text I included on the re-assign message. I'm re-posting it so that it's more visible.
Note that my proposed solution for libsilc will almost certainly require the use of epoch, and the present naming and numbering scheme for libsilc is not very useful. ========= The policy posted in the initial post in this thread seems to be relevant. The problem with the soversion seems to be real. I don't see anyone saying otherwise. When I install libsilc, I see /usr/lib/libsilc-1.0.so.2.1.0, (as is reported in this bug report). The mechanism suggested by Steve Langasek for extracting the version information from the binary using objdump -p seems to be correct, though of course the naming he uses to prefix it is just a suggestion. The disagreement with this is a statment attributed to Toma "I won't follow this policy". No technical reasoning is given. His suggestion -- that every developer should compile his/her code against the current up-to-date libsilc -- is that every user of libsilc who doesn't have the most current unstable version installed should expect to have libsilc be broken. This is a grave problem. But it doesn't seem to be a technical problem. If we have a developer who refuses to follow policy, without giving any good technical reasons for doing so, that's really a matter for debian as a whole. If, as reported, the developer is willing to let someone else take over the package, I think that's what should be done. If no one else takes over this package and releases a fixed version before midnight september 10, 2005 (GMT), I'll release a fixed version myself, and close this bug. (I'd do it sooner, but I've got other things I need to deal with before then.) I'll follow up here if I uncover any other issues. Thanks, -- Raul
