Best practices for attaching debug symbols to system libraries during development?

I'm at a stage in a project where it would be really handy to have a debug version of a system package installed. On Ubuntu at least, adding the debug symbols to a library is a piece of cake. Practically every package has a -dbg variant that provides all the symbols you'd need for a useful backtrace. However, I'm currently on Arch linux, where the general concensus is to edit the user makepkg.conf file, adding whatever debug flags to (C|CXX|CPP|LD)FLAGS. Then re-build the package yourself, and replace the current, optimised version with the debug build. Well, I suppose that's fair enough with a "source-based distribution", but it gets tedious pretty quickly. So, what is / are the best practices for attaching debug symbols to a system package? How do other packagers do it? I think I've seen that strip can extract debug symbols and save them in external files. Is it possible for gdb to pick up those symbol files during backtraces, with system applications not even bothering to look for them? How does that work, from a packagers perspective? It's just an idea, but is it a good idea to create a chroot environment in which to develop? (I have a problem atm where a package has an ABI incompatibility between its debug and release builds, which is a bit of a pain. Everything linked to its shared lib also complains about missing symbols, so reverted to optimised build..)