My immediate question: I need to build a dual binary (a runtime and a development) package from a single source package, called "wcstools", which I am creating with dh_make and dpkg-buildpackage.
I've seen various references to how these should be "built in debian/wcstools and debian/wcstools-dev" instead of just in "debian/tmp" -- but I *haven't* found out how to make that happen. Is there something else I should be reading, or have I missed the section in what I have read (which is the Debian Policy, Debian NMG, and Debian Developer's Reference -- I admit I didn't read them word-for-word, but I'm fairly certain I would've found this if it were in there in an easy to find place. Or maybe it's in front of my nose, I've been wrong before.). Some background, by way of introduction to me and my packaging project: Well, I followed the advice in the NMG and stuck to "single binary packages" for my 1st & 2nd packages. Now I'm on #3, though, so that rule doesn't apply anymore. ;-) What I am doing is creating a set of *unofficial* deb packages to support a scientific applications suite. For most of these packages, it should be possible (someday) to move them into the Debian "main" distribution (DFSG-okay licensing), although many will require more work than I'm going to do on this first pass (not compliant with Policy -- most are large, static-linked packages, and there's little support from upstream for fixing that). And like it or not, I'm on a tight deadline, so I'm only going to try stuff I think I can learn in time. I've read (briefly) the Policy document, the New Maintainer's Guide, and the Developer's Reference. I still feel like there's a lot of information that probably seemed too obvious to the writer to mention, but which is nevertheless confusing if you don't have the same experiences. Perhaps obviously, I've been following the NMG approach, using dh_make and dpkg-buildpackage, and modifying the upstream Makefile. Now I need to make two binaries -- a "wcstools" and a "wcstools-dev" for the "World Coordinate System" tools package that I'm working on as Deb #3. (The other two, ds9 and funtools "FITS Users Need Tools", which seem to have been successful, created only single binary packages). Which is where the above problem arose. It is my hope that I can use this opportunity to learn the Debian package management system and eventually join Debian and see these packages go into main, but at this point, I'm just trying to learn the tools. And the packages that I'm maintaining, are -- almost by definition -- the ill-behaved ones that don't easily fit the FHS or Debian policy standards. Therefore, they will require work, and you'll probably hear more from me about it over time. ;-) Until that time, my plan is to set up apt-get-able versions of the unofficial packages, mainly for the benefit my clients, but world accessible. There are also whole areas of gcc and make details that I simply never learned, such as how .so files actually work (back when I did C programming they either didn't exist or didn't exist on my platform -- which was MS-DOS, now I use only Python for development, which is about all I have the time to pursue). I briefly entertained the idea of making the libwcs.a file that gets built in wcstools into a libwcs3.so -- but reading the Shared Libraries section of the Debian Policy manual cured me of this fantasy. ;-D And yes, I've checked, of the 50 packages I'm working on, only about 20 or so already have been packaged for Debian. Most of the interesting ones haven't been, although some are available as RPMs (yeah, I could technically use alien for those, but they would generally install in /usr/local as a result, AFAIK). Anyway, nice to meet you, and "yoroshiku". Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
