I am looking for a succinct howto on the basics.
Some good guides for making packages (deb, rpm, etc)
packaging
Related Solutions
Main difference for a package maintainer (I think that would be 'developer' in Debian lingo) is the way package meta-data and accompanying scripts come together.
In the RPM world, all your packages (the RPMs you maintain) are located in something like ~/rpmbuild. Underneath, there is the SPEC directory for your spec-files, a SOURCES directory for source tarballs, RPMS and SRPMS directories to put newly created RPMs and SRPMs into, and some other things that are not relevant now.
Everything that has to do with how the RPM will be created is in the spec-file: what patches will be applied, possible pre- and post-scripts, meta-data, changelog, everything. All source tarballs and all patches of all your packages are in SOURCES.
Now, personally, I like the fact that everything goes into the spec-file, and that the spec-file is a separate entity from the source tarball, but I'm not overly enthusiastic about having all sources in SOURCES. IMHO, SOURCES gets cluttered pretty quick and you tend to lose track of what is in there. However, opinions differ.
For RPMs it is important to use the exact same tarball as the one the upstream project releases, up to the timestamp. Generally, there are no exceptions to this rule. Debian packages also require the same tarball as upstream, though Debian policy requires some tarballs to be repackaged (thanks, Umang).
Debian packages take a different approach. (Forgive any mistakes here: I am a lot less experienced with deb's that I am with RPM's.) Debian packages' development files are contained in a directory per package.
What I (think to) like about this approach is the fact that everything is contained in a single directory.
In the Debian world, it is a bit more accepted to carry patches in a package that are not (yet) upstream. In the RPM world (at least among the Red Hat derivatives) this is frowned upon. See "FedoraProject: Staying close to upstream projects".
Also, Debian has a vast amount of scripts that are able to automate a huge portion of creating a package. For example, creating a - simple - package of a setuptool'ed Python program, is as simple as creating a couple of meta-data files and running debuild. That said, the spec-file for such package in RPM format would be pretty short and in the RPM world, too, there's a lot of stuff that is automated these days.
whohas package (link) may help you.
Example
% whohas pidgin|grep "pidgin "
MacPorts pidgin 2.10.6 https://trac.macports.org/browser/trunk/dports/net/pidgin/Portfile
Slackware pidgin 2.7.11-i486-3sl slacky.eu
Slackware pidgin 2.7.0-i486-1 salixos.org
Slackware pidgin 2.7.0-i486-1 slackware.com
OpenBSD pidgin 2.9.0-gtkspell 8.3M
OpenBSD pidgin 2.9.0 8.3M 16-Aug-201
Mandriva pidgin 2.10.6-0.1.i586 http://sophie.zarb.org/rpms/a6ec6cd30f5fa024d14549eea375dba4
Fink pidgin 2.10.6-1 http://pdb.finkproject.org/pdb/package.php/pidgin
FreeBSD pidgin 2.10.6 net-im http://www.freebsd.org/cgi/pds.cgi?ports/net-im/pidgin
FreeBSD e17-module-everything-pidgin 20111128 x11-wm http://www.freebsd.org/cgi/pds.cgi?ports/x11-wm/e17-module-everything-pidgin
NetBSD pidgin 2.10.6nb5 10M 2012-12-15 chat http://pkgsrc.se/chat/pidgin
Ubuntu pidgin 1:2.10.0-0ubuntu2. 695K oneiric http://packages.ubuntu.com/oneiric/pidgin
Ubuntu indicator-status-provider-pidgin 0.5.0-0ubuntu1 7K oneiric http://packages.ubuntu.com/oneiric/indicator-status-provider-pidgin
Debian pidgin 2.7.3-1+squeeze3 706K stable http://packages.debian.org/squeeze/pidgin
Debian pidgin 2.10.6-2 591K testing http://packages.debian.org/wheezy/pidgin
Debian indicator-status-provider-pidgin 0.6.0-1 33K testing http://packages.debian.org/wheezy/indicator-status-provider-pidgin
Source Mage funpidgin 2.5.0 test
Source Mage funpidgin 2.5.0 stable
Source Mage pidgin 2.10.6 test
Source Mage pidgin 2.10.5 stable
Gentoo pidgin 2.10.6 http://gentoo-portage.com/net-im/pidgin
Gentoo pidgin 2.10.4 http://gentoo-portage.com/net-im/pidgin
Best Answer
The ubuntu packaging guide is a good introduction. The rest you can learn by studying existing packages, and reading manuals (CDBS, and of course Debian Policy). However, as directhex said, it depends a lot on the kind of package you work on.
For RPM, I liked the Mandriva wiki, and some Fedora RPM Guide and Guidelines.