On Sun, Jan 31, 2010 at 01:21:54PM -0800, Bruce Korb wrote: > Kurt Roeckx wrote: > > Hi, > > > > I've NMU'd your package. Please find the patch that I used > > attached. > > > > Some comments: > > - You might want to use something like: > > dh_makeshlibs -V "libopts25 (>= 1:5.10)" > > This would require that you update this properly on new release. > > I've just used -V would would just base it on the upstream > > version. > > Probably something to always do. I'm not a Debian packaging person, > so I don't really know what "dh_makeshlibs" does.
dh_makeshlibs will create a file (shlibs) that it shipped with a library that tells other libraries which dependecies it should use in case they link to that library. The -V option will create the most strict requirements by default, which isn't always needed. If you release a 5.10.1 version, it might be fully compatible with 5.10 and just contain bug fixes. It could be that anything linked against a 5.10.x version should work with the 5.10 version, so a depedency on that or higher might be enough. But 5.10.1 might also introduce new symbols for instance, and then we'd need to make sure that packages depend on 5.10.1. Anyway, how this works is probably not that interesting for you. What we'd like to know is which versions are fully compatible with each others. I assume that 5.10.x will keep compatibilty and that if you change something in a way that it's not fully compatible that you change it to 5.11. But it's not important that you do it like that, any system that you use should work for us. > > - I've just removed some code from autoopts-config.in. It says > > it's autogenerated, but I can't find the source for that. > > Upstream probably added this code for some reason, so might want > > a better patch. In any case, there is no reason to add the > > rpath on a Debian system since it's configured for /usr/lib and > > that's always in the dynamic linker's search path. I didn't > > remove the -L/usr/lib because it doesn't hurt anything. > > That stuff is there because without it, when you run a build and > "make check", the executables will link against the installed version. > Sometimes it causes breakage, but most times it silently tests the > installed libraries instead of what you think you're testing. > I need a reliable way to ensure that "make check" finds the autoopts/.libs/... > stuff before any installed versions. Portably. Not just for Debian. :( Doesn't libtool do that for you? If you're linking against a non-installed library it should create an rpath. If something is broken, feel free to file a bug against the libtool package. (I'm Debian's libtool maintainer.) Kurt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
