This one time, at band camp, martin f krafft wrote: >i don't really know what to do in this case. Rex Tsai wants to >package proxychains. The package contains libproxychains.so, but >ther are no SHLIBS. i told him that instead, he should package >libproxychains separately, and make the proxychains package depend >on that. To that, he writes:
There is nothing wrong with a program and a shared library that it uses being in the same package, given that the shared library is of no interest to any other program on the system. >> Thank you. But libproxychains* is useless. The packages don't >> provide useful header files. And the *.so file are for runtime. >> Because proxychains use LD_PRELOAD to intercepting socket function >> calls. > >My inclination is to include a lintian override and to package it as >is. The library is a .so, but it's not usable outside the package, >so it's not really a SHLIB. i want to get your okay first... You don't want two packages here. It sounds like the .so and the program are tied closely together, so there will be little gain from separating the two into separate packages -- they'll both have to be upgraded together anyway. And you say that nothing else is going to use the library, so there's no point splitting it out. (And electric-fence sets a precedent for packages containing LD_PRELOAD library and nothing else, so including a LD_PRELOAD library *and* a binary is certain to be ok.) -- [EMAIL PROTECTED] http://people.debian.org/~jaq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
