If you have a packaging system for open source programs (and who doesn't these days) and you have the concept of 'source packages' as distinct from the compiled binary packages (which you probably do), there are four things that source packages need:

• metadata about the package (or packages), such as the version and description.

• the original 'upstream' source code (or some proxy for it).

• whatever changes and additions you make to the upstream source code, if there are any (and there usually are).

• instructions on how to compile the code and package it.

(If you are building your own code you can generally leave out the 'local changes' stuff, but you still need the the metadata, the source code, and the build instructions.)

In theory if you are sufficiently crazy you can merge together the middle two pieces, so that the source code in your source packages is pre-modified and ready to compile. People who do this generally find out how bad an idea it was when they want to start updating their package builds to the next upstream release.

(I'm not sure if any actual packaging system has made this mistake, but plenty of people certainly made it on their own in the days before formal packaging systems when you plunked stuff in a local directory, hacked it up to work, and then did 'make && make install'.)

Actual packaging systems vary tremendously in how they handle and represent all four of these things. For example, I understand that the packaging system used by the *BSDs generally doesn't even store the original upstream source code in the source package and just includes information on how to fetch it at build time.

(While I think that there are better and worse approaches to handling all four things, I don't think that there's a clear right answer as to how to do it. And to a certain extent the best approach depends on how your system is likely to be used; the obvious case is something designed to package your own source code is likely to look quite different from a system aimed at packaging other people's code.)