Thanks for all the replies, this one brings up some related questions... On Tuesday 09 September 2003 07:55 pm, Neil Roeth wrote: > The approach I took with a multi-binary package that I created from scratch > was to do the configure and make, then set DESTDIR to $(CURDIR)/debian/tmp, > export it, and do the make install. [...]
So, there's never <packagename>.rules files, then? Or just in the method that Neil describes? Actually, in my case there is no "make install" -- it's a very simple Makefile. As shipped, the package builds a bunch of binaries in "bin/" (which means $DISTDIR/bin if $DISTDIR is the distribution directory), there's suggestions in the "Install" document about what to do after that, but no automation. Is it better practice to alter the Makefile to add an "install" target, or to put that code directly into the debian/rules file? And are those in fact, my only two options? And anyway, while I'm posting -- this package is designed to be driven by some database sources (one is supposedly 80 GB, though I haven't seen it yet). You can install these from CDROMs or download them (from NSSDC -- I have not checked, but the usual status of such sources is "US Govt 'Copyright Free'"), but there's also a possibility of using an RPC call to the URL of a database server. Given this kind of situation, I'd probably prefer it if there were a /etc/wcstools.conf, but in fact, the code doesn't seem to support this -- there are hard-coded defaults in the C sources, which can be overridden by environment variables (as shipped, they seem to point to various directories under the top-level directory "/data"). I'm thinking about altering the sources to point at remote database servers, since that seems like the right thing to do for the typical end user, so that it'll work out of the box (and I'm *not* shipping 80GB files). However, there are probably more than one server to choose from, and the end user *might* have the CDROM data, so I'm not sure what the "best practice" is here, either. Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
