You should highly favour building packages on a clean system. That's because production systems are always polluted in the one or other manner or get so with time. Not so much because of the machine more because of us.
Some possible solutions are chroots, virtual machines (virtualbox, qemu, ...) or second installations. Optimally they're combined with some sort of snapshotting. This means you setup a base system which you keep up-to-date. When building a package you only install the necessary packages, do the build (and the testing). Afterwards you return back to your unmodified base system. Therefor every package is built on a fresh and clean system.
I'm starting to use the chroot approach and combine it with the snapshotting capabilities of btrfs. To optimize the workflow I wrote a tool called pad:
http://www.salixos.org/forum/viewtopic.php?f=22&t=3374
One should note that with chroots (as with second installations) you're limited to the architectures your processor can run unless possibly did some magic with qemu. While that's at one hand the advantage (you get native speed unlike with virtual machines), it can also be a disadavantage for the aforementioned reason. Anyway if you've got a 64-Bit processor and are running a 64-Bit kernel, you can build packages for 32- and 64-Bit which is all you need with Salix.
In the end we can't do more than highly recommending this. We have no way to check how you're building packages and there's nothing bad about not using separate packaging systems. Other installations can be as clean as a separate one and even if they aren't the resulting package is not necessarily affected. But it's a pretty sensible measure.
As far as awesome is concerned. Probably the best approach for people who really want awesome is a user repository. You can pretty much do anything you want there. Of course you should try to ensure quality and compatibility. If done properly it's not that bad at all.
These are the current possible "solutions" for the Salix repository.
With a cairo package we would unleash possibly unstable software on all Salix users.
With a cairo-xcb package we would end up in dependency hell. One package could requie cairo the other one cairo-xcb but they should not be installed at the same time. After all most packages require cairo, one would need to change their dependencies to also allow cairo-xcb which is was too uncertain and especially to big a change.
A new idea: A cairo-xcb package which installs its file to a different location than the cairo package (awesome would be told to use the files from there everything else the default cairo ones) thus preventing the conflict. This is not really clean either. But it circumvents the two previous big problems at least.