How to switch from rpm packaging to debian packaging.
If you do want to switch your packages from rpm to debian style then you will surely come across two sources of information
(a) if you google for "rpm to debian" you will find lots of answers that will point you to use "a/ien" to convert an existing rpm binary. Actually, it did not work on my rpm archives, it requires sudo even in the simplest cases, you will loose the option to set proper package dependencies, and you will hardly have a chance to upload these deb packages to any debian/ubuntu/whatever distribution for inclusion.
(b) if you look for a primer to debian packaging (spec) files then you will find the PackagingGuide/Complete but this source will only confuse you with a dozen tools asking you to use them in a build structure that seems from outer worlds. It does not give a clue which rpm *.spec fields and *.spec sections must be placed where to get a similar result.
Actually, it took me 10 hours to get an idea about the most import difference between rpm and debian packaging: in the rpm world you have a "SOURCES" directory where all tarballs and patches are placed, *.spec file in the "SPEC" directory, and as soon as you run "rpmbuild -ba *.spec" you will find the resulting "*.rpm" in the "RPMS" output directory. This is a one-phase process using a single tool - you download tarballs and patches to one place and you get binary packages in the other place.
In the debian world you have ALWAYS a two-phase process. You are required to invent an explicit per-package build directory. It may be a temporary directory but you must choose one. Now, you use one set of tools to unpack the tarballs and patches to the build directory and when you are done then you can run a second set of tools to compile and package everything. In the easiest case this goes as follows:
(cd downloads && dpkg-source -x specfile.dsc target-directory) (cd target-directory && dpkg-buildpackage)
The specfile.dsc is ONLY about creating the intermediate target-directory. It might contain metadata lines like the following that describe the required INPUT files:
Format: 1.0 Source: zziplib Binary: libzzip-0-13, zziplib-bin, libzzip-dev Version: 0.13.49-3 Build-Depends: debhelper (>= 5), autotools-dev, pkg-config, zlib1g-dev, python, quilt Files: a7fe5a706a4b01632fbea51a03d468f9 814997 zziplib_0.13.49.orig.tar.gz 28fb5f0f3da6d680e7dd497105cdd218 6537 zziplib_0.13.49-3.diff.gz
The information for the actual build will be contained inside the target-directory/debian/* files - in the example these would be unpacked from the *.diff.gz which is a common way for debian maintainers to package their add-on files (instead of using a tarball).
The debian/control files will again contain metadata but in this case about the resulting OUTPUT packaging structure - as perhaps you want have multiple output *.deb files. The multiple rpm '%files' would then represented as debian/*.install files that (quite similar to the rpm format) contain file-globs.
Source: zziplib Section: libs Build-Depends: debhelper (>= 5), autotools-dev, pkg-config, zlib1g-dev, python, quilt Package: zziplib-bin Description: library providing read access to ZIP-archives This library is using the zlib library to allo for....
Note how "Build-Depends" is a duplicate in the *.dsc and debian/control. Anyway, there are more debian/* files like the debian/rules makefile and pre/post shell scripts which are slightly different from rpm but for their structure one can read up the generic packaging howtos of the debian guys.
A two-phase process allows you to create a debian source directory by simply copying cvs checkout trees into a common place. May be you have one cvs tree with the vanilla project sources and one cvs tree with the debian/* files and the per-distribution patches. Then just choose a target-directory and copy both trees into the same place - and you are done with the first phase being ready for dpkg-buildpackage.
With the rpm world you would be required to make a tarball of all your input source trees and to to place them in the SOURCES directory. Only then you would be allowed to run the rpmbuild command which would unpack them in the '%setup' section immediatly followed by '%build' and '%install'.
The rpm approach has the advantage of following a good toolset design which obeys to the "make simple things simple - make complex things possible" pricinple. In the simple case you download tarballs, you fill in the sections of a template *.spec file and you are pretty much done. In the debian case you need to populate a dozen files with boilerplate code and you have to run atleast two tools plus managing the intermediate target-directory.