The core problem with developers doing their own packaging
September 12, 2012
As I've discussed, Linux package systems generally have some degree of support for developers embedding all of the things you need for source packages directly in the master source and distribution tarballs or the like. However, pretty much everyone now discourages developers actually doing this; these days, distributions would generally much rather have you let them do the packaging (and many of them will ignore your work if you try to include it).
There are a number of pragmatic reasons for this; one of the larger ones is that it's not very common for developers to also be packaging experts for a Linux distribution. But let's set that aside and assume that, say, you're an expert Debian Developer and you're going to build the Debian packages for your program. There's still a problem with such 'native' packages.
The core problem with including the packaging data in the master
source distribution is that this can only be packaging for one
distribution. Debian packages are not Ubuntu packages and Ubuntu 12.04
packages are not Ubuntu 10.04 packages; your in-tree
(Among other things, notice that this sort of native package requires changing the distribution source in order to make a package update. There are many reasons for doing this that have nothing to do with changes to the source, including things like 'there's a bug in GCC that might have affected this program, we need to rebuild it with the fixed GCC just to be sure'.)
The practical best case result of embedding packaging control files in the master source is that one lucky distribution version gets to use the master source as a 'native' package, at least for a while, and everyone else puts together a non-native package with some alterations (and then ignores or erases your bundled control files).
In my view it's easier overall to always have a 'non-native' source package, one with packaging control files separate from the upstream source distribution. This creates uniformity and avoids the problem of having to convert a native package to a non-native package during things like mass rebuilds.
* * *
Atom feeds are available; see the bottom of most pages.