On Sat, May 21, 2005 at 12:44:59PM +0300, Shachar Shemesh wrote: > Neil Williams wrote: > >On Friday 20 May 2005 10:22 am, Shachar Shemesh wrote: > >>No, it's the same release. The deb file there is an alienated RPM, and > >>is not in a state that can go into Debian. > >So your options for this one are limited - you need to retain binary > >compatibility and can't go changing the SONAME or package name without > >breaking things. You CAN implement a SONAME where one is missing, but I > >don't see that skipping 1 is going to be any good. > I think a more interesting question is whether I can NOT implement > SONAME where one is missing? It seems that upstream does not like the > idea of SONAME, and prefers to do without it. I wouldn't have insisted, > except that without SONAME the package is not lintian clean. > I have still not totally given up on convincing him, though, so I'll be > in touch.... :-) It's not acceptable to install a shared library without an SONAME for two reasons: - if the library's ABI changes and the filename doesn't change, the new library package will have to conflict with the old package, forcing removal of all other packages using the old version of the library - if at a later date upstream comes to their senses and starts using an SONAME for their shared library, the *-dev* package will still have to conflict with the old library package for the same reason, forcing removal of packages depending on it Introducing an SONAME to a library in Debian when it doesn't have one upstream isn't great, but the only sensible alternative is to not ship it as a shared library at all. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature