Michael Banck <mbanck@gmx.net> writes:
> The package features quite some libraries, I split them up
> into two logical parts, but I'm hesitant where to put them, ie. under
> /usr/lib or some directory /usr/lib/mpqc for example.
Just for clarification -- we're talking about _shared_ libraries, right?
> The problem is with the names, they look quit common, e.g. libcontainer,
> libmisc, libref, liboptions...
Ugh. While I can't find libraries of with these names already in
Debian, sooner or later, someone will have the same stupid idea of
naming her library "liboptions". (IIRC some BSDs actually have a
standard libmisc.)
> 1. Convince upstream to rename them. Yuck, I haven't even contacted them
> about this, they follow some strange file-hierachy-policies anyway, but
> I could try.
Best. May be hard.
> 2. Rename them myself to something like libsc_container, etc. This would
> be very bad habit at least I guess.
Yup. No compatibility with other platforms or a hand-compiled version.
> 3. Keep them in /usr/lib and hope that the packages get installed.
Ugly.
> 4. Dump them in /usr/lib/mpqc or perhaps /usr/lib/sc and /usr/lib/mpqc.
> There is a sc-config program remotely similar to gtk-config ('sc-config
> --cflags' outputs the flags libsc was compiled with rather than the flags
> programs against libsc should be compiled with) which outputs the
> library directory when called like 'sc-config --libs'.
>
> Would the 'sc-config' program be sufficient or would I have to change
> /etc/ld.so.conf (something I'd like to avoid)?
ld.so.conf, yes, or binaries won't find your library in
/usr/lib/<mumble>/. An alternative is to wrap all binaries in scripts
that set LD_LIBRARY_PATH accordingly. -rpath is another one, but
outlawed in Debian.
> Dropping the headers directly under /usr/include would just result in
> three directories: math, utils and chemistry, which wouldn't be very
> beautiful either.
Exactly. Put them in a subdirectory, teaching dependent programs to
find the right location for include files is easier than for shared
libs.
> Oh, and another thing: dpkg-genchanges (I think) complains that the
> source packages doesn't have a Section:. Is this a problem?
Section is mandatory, see policy appendix C.2.2. It is not clear to me
why -- users are never presented with the section of a source package.
--
Robbe
Attachment:
signature.ng
Description: PGP signature