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 debian/ directory can only be right for one of them. What this really means is that packaging metadata is tied to the distribution, not to the source code. Putting the packaging metadata together with the source code is yoking together two very separate things in a way that artificially constrains both of them.

(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.