Debian packages are like tar files - they contain a copy of the file system. To create a Debian package...

1. Install the tarball in a build directory.
2. Add a DEBIAN directory with the control files. I found this article helpful.
3. Create the package with dpkg --build.

I would start by learning GNU s autotools: autoconf and automake. They make it very easy to install the program in a build directory. You mentioned ./configure. So I assume ythis project already has some of the structure. From the description, it sounds like the project might need...

• Entries in configure.in for files in "book" and "glade".
• Makefile.am files in "book" and "glade".

Putting it all together, the following commands result in a package file named project.deb.

# ./configure --prefix build/usr
# make && make install
# dpkg --build build project.deb

Perhaps this blog post may be of help to you.

It thoroughly describes the structure of a deb package, which is as follows:

<YOUR PACKAGE NAME>
└── deb
    ├── DEBIAN
    │   ├── conffiles
    │   ├── control
    │   └── preinst
    └── opt
        └── <YOUR APPLICATION>
            └── <Your Application Contents>  

Basically, you have a deb folder inside the package with the following 2 mandatory folders inside:

• DEBIAN - containing files that describe the deb package itself
• file-system structure mirroring the destination for the package installation. In the above example, the package will be deployed inside /opt/<YOUR APPLICATION> directory.

From the DEBIAN directory, you must have at least the control file, which is plain text. It needs to contain entries in specific format that is described in detail in the linked page. Here is a mere example (taken from there) with a sample control file:

Package:packagingmono
Version:1.0
Maintainer:Mikael Chudinov <mikael@chudinov.net>
Architecture:amd64
Section:net
Description:Template for Debian packaged Mono application.
Depends:mono-complete (>=3)

• Package must be your package name. Allowed is upper/lower latin letters, numbers and -.
• Version - the package version. I d recommend using the assembly version for that field.
• Maintainer - the package developer(s) name and contact info.
• Architecture - either i386 or amd64. If you want to distribute your application optimized for x86 and x64 as separate executables per platform (I mean built explicitly for x64 or x86, not using AnyCPU), then you should produce separate .deb packages for each, and set the Architecture field appropriately. The rest of the fields may still be the same.
• Section - optional, could be any of the allowed package categories in the debian apt system.
• Description. Consist of two tokens - short description (the first item before a new line symbol) and optionally longer one (the text after the first new line).
• Depends - a list of dependencies to your package. The example states mono-complete which is the package name for the mono runtime, and further restricts it to be higher or equal to version 3

Important thing to know about a deb package is that you can actually put an entire application (the contents of the bin folder) into a single package. There is no need to put the referenced libraries in separate packages and mark them as dependencies, the latter makes sense if you plan to install other applications that would rely on the same libraries. Besides, packing the application together would not allow the dll-hell problem to one day become a package-hell problem. A drawback to this is that the size of the package might become larger.

The article also recommends some native GNU/Linux tools that will aid you in the package creation. For example xbuild can be used to run an MSBuild file that will do the packaging for you. This will help make things more familiar to Windows developers. The lintian tool may also assist you in fixing issues with the produced .deb file. The rest of the tools are intermediate utilities that are invoked during the MSBuild packaging process.