Re: Problems with new policy
On Mon, Nov 26, 2001 at 08:38:19PM +0100, Federico Di Gregorio wrote: > going slightly off-topic, this problem is a good example of i dubt i > always had with debian sonames. shouldn't a package name libfoo4 provide > a library named libfoo.so.4.x.x? That depends on whether the library is actually called foo4 (i.e. if the link line is -lfoo4) or whether it's just version 4 of libfoo. Even in the latter case there's no reason why the soname should have to match the version number of the package, because you only need to change the soname when you make changes that affect binary compatibility. > so, the right name is > > libsip-python2.1.so.2.0.0 If the soname wanted to be 2.0.0, then yes, but this means that people who link against the library will have to use -lsip-python2.1, potentially breaking source compatibility with other distributions. > or > libsip2-python2.1.so This (no soname) is only allowed if you regard the library as private and keep it somewhere other than /usr/lib. > or > > libsip.so.2.python2.1.x.y... ugly! it is even possible? That sounds best to me in the absence of any better coordination from upstream, or being able to use a single libsip. I agree that it's ugly, though. Do libsip upstream set any sonames? Is it important that binaries linked against it on Debian can be run on other distributions? -- Colin Watson [EMAIL PROTECTED]
Re: Problems with new policy
On Tue, Nov 27, 2001 at 03:18:08AM -0600, Colin Watson wrote: > > or > > > > libsip.so.2.python2.1.x.y... ugly! it is even possible? > > That sounds best to me in the absence of any better coordination from > upstream, or being able to use a single libsip. I agree that it's ugly, > though. > > Do libsip upstream set any sonames? Is it important that binaries linked > against it on Debian can be run on other distributions? The actual library is: libsip.so.6.0.0 (Taken directly from the upstream compile). By now, it's installed at /usr/lib. When 2.* were not GPL compatible, I only packaged sip/libsip for Python 1.5. Now we have multiple version of Python, and I want to package it for all that versions. I'd better ask to the sip development list if someone has done something for having two python versions working at a time with it. In the meantime, I'll package the various versions with a Provides: libsip and Conflicts: libsip (all other options seem too ugly). Thanks for all the help :-)
Re: Packages that still need to be updated to new python policy
> "AT" == Anthony Towns writes: AT> Bug#119218: gnats2w 0.15.2 gnats2w 0.15.2 all This one is orphaned upstream and is going to be removed from the distribution. I'm waiting a bit if anyone wants it and if not then I'll ask for its removal. I assume it has already been removed from woody because of its RC bug, so there's no need to rush with its removal. Milan Zamazal -- The rush to reproduce Microsofts window environment seems to overshadow the design process of determining what a window environment should be, and what its ultimate users will want. -- Barry Fishman in gnu.misc.discuss
