I dont know dkpg, but with the aim to bring some light onto the question, here's was i would conclude in a simple way.
So, what i say now, might be technical incorrect but is thought to get a raw draft of the greater image.
There are 3 package types.
1) compiled (i386/x86_64, ..., any ARCH specific)
2) copy files (noarch, scripts)
3) devel/debug and source packages (they are NOT the same, and usualy are not 'usable' for regular users)
Obviously, everything that needs to be compiles, needs to be labeled which ARCH is was compiled for.
A packaging system, such as dkpg/apt-get/rpm/aur... offer various tasks to simplify the process of getting sourcecode into a working package for the system.
This includes the use of macros inside of the (on redhat systems its called
specfiles (for rpm packages, dont know the proper term for apt-get-configuration-deb-files.
For RPM specfiles, if one doesnt pass a certing option within that file, the packaging system automaticly assumes that the packages supports the same arch as the host system is.
This said, it also adds the according string to the package, usualy at the right place, unless manualy modified.
In specfiles, the required option to add would be:
BuildArch: noarch if you want to make a package of scripts, images, html docs or manpages or just anything that doesnt need to be compiled to be usefull.
I dont know much about dkpg based systems, but i would assume, when you end up having both, 32 and (as in: or) 64 bit packages, there is somewhere an error in your settings or scripts.
Usualy, but not always, an applications requires only 1 kind of an arch dependency.
This said, here are some questions:
When did it last work?
What did you change since?
Were there any other improvements? ("damages")
Did you copy paste code?
Changed code or project configuration?
Hope this helps