[Justin Pryzby] > In which case, should the shared libraries go into a separate package?
I wouldn't bother unless there are multiple binary packages already
which will require the library, and they don't already depend on each
other. And this is probably a fairly rare case.
Basically, if there's no reason for anyone to install the library
package but *not* the binary package that requires it, then there's no
reason the library package should be separate.
> 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)?
/usr/lib/pkg/, and I would use rpath. Why not? The problems with
rpath do not apply to the case where libraries and binaries are tightly
coupled, like they're built from the same source and are in the same
binary package.
> Is it still okay if the binary interface is not at all stable, or
> guaranteed to be compatible between versions?
I think it's fine - especially if you don't have a separate library
package, but even if you do - just so long as you have a (=
${Source-Version}) in your Depends lines, as you said.
> 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?
I agree, but maybe someone else can think of deeper reasons.
Note that you wouldn't separate foo-lib just for arch-dependent
vs. arch-independent reasons anyway - at least if we're talking about
ELF libraries here. Because arch-independent packages can't make use
of ELF libraries directly anyway.
Peter
signature.asc
Description: Digital signature
