On Tue, Nov 06, 2001 at 08:44:30PM +0100, Robert Bihlmeyer wrote: > Michael Banck <[EMAIL PROTECTED]> 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?
Yes. Well, both shared and static. I thought they were normally in the same directory. sc-config below is about the development/static part though, I mixed that up a bit, sorry. > > 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.) Well, they rely on the user/admin installing their stuff below a 'target-directory' and tune ld.so.conf. It took quite some time to get them into a FHS-compliant state although they're using autotools. > > 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. OK, I'll ask them. I need to convince them that searching for 'elements.txt' in $(SCLIB_DIR) hardcoded isn't really the right thing to do anyway. > > 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>/. Yep. Logical error on my part confusing normal and development packages. > An alternative is to wrap all binaries in scripts > that set LD_LIBRARY_PATH accordingly. -rpath is another one, but > outlawed in Debian. Well, the run-time stuff from the package knows about where the libraries got installed from ./configure I think. The other application I know that uses MPQC has to be ported to the current version first to find out. But still, I think changing ld.so.conf is the most reasonable thing to do until upstream changes the names. > > 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. OK. > > 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. Thanks, I fixed this by setting source section to science. That's where the whole beast comes from at least. thanks a lot, Michael
