Re: dh_shlibdeps in = warnings; dh_shlibdeps out = cyclic dependency on self
On Tue, Sep 06, 2005 at 07:18:17PM +0200, Frank K?ster wrote:
> Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
>
> > On Tue, Sep 06, 2005 at 05:56:54PM +0200, Frank K?ster wrote:
> >> Justin Pryzby <justinpryzby@users.sourceforge.net> wrote:
> >>
> >> > Could someone else also comment on how applications should deal with
> >> > shared libraries which are not intended to be used by other programs?
> >>
> >> If they aren't used by other programs, there's no need to produce a
> >> library. Perhaps it's convienient to create static libraries during
> >> compilation and link against these, but shared libraries are of no use.
> > What if there are many binaries (10s of them) in your package, and you
> > want to use shared libs purely for resource efficiency (disk and
> > memory)?
>
> You're right, that's an other reason for a shared library.
In which case, should the shared libraries go into a separate package?
What should they be named (filenames and sonames)? Should they be in
/usr/lib/ or in /usr/lib/pkg/? If /u/l/pkg/, what is the recommended
way of linking them (LD_LIBRARY_PATH, maybe, but surely not rpath)?
Is it still okay if the binary interface is not at all stable, or
guaranteed to be compatible between versions? I'm thinking of the
case where a Debian packager adds shared lib support for better
resource efficiency, but upstream doesn't implement it, and interfaces
change at potentially every new release. Is it sufficient (if the
libs are in a separate package) to have the libs and the binaries both
Depends: pkg-{libs,bin} (=${Source-Version})?
It seem to me that there is no reason to requires libs to be in a
separate package, though it might be convenient to make this division,
but probably no deeper reason, correct? For a multiple-binary
package, it could be used as one of the arch-dep packages, if the
indep packages are significanly large to warrent the split.
Thanks,
Justin
Reply to: