There's nothing terribly wrong with this approach, and it's the typical first step along the way to more complicated debugging schemes. Once the script is working you'll probably go on to set the debug flag from an environment variable or command line option as I did.
in reply to Debugging in packages
The reason for other recommendations is that this scheme makes debugging an all or nothing mechanism. When I was working on a very complex system with many classes, I needed a way to get run-time information from the classes of interest, without clogging output completely with the full range of feedback I'd coded into the system. For that I used an initialization that parsed out which classes should spit out run-time information, then went on the specialize it more so that the instances associated with certain tables would have debugging on, while others were off.
One disadvantage to using a global variable is that it is prone to typos. If your code refers to $main::DEBYG somewhere you'll have to catch it yourself; it's a valid variable name.
Also, you can shorten your modifiers:
unless you just prefer the way the parenthesis look.