UNIX for Advanced & Expert Users

Greetings.

After rifling through the policy manual to some significant extent, I've come to a question which doesn't seem to have any forthcoming answer out "in the wild", so here it is

During dpkg installation processing, some libs wind up with an ":i386" or ":amd64" architecture string naming convention in conjunction with their package management ( /var/lib/dpkg/info/ ) filesets, while some do not. The package-side selection processing which occurs seems quite elusive.

Indeed, after examining a couple of common deb specimens (libgdbm-dev and libgdbm3) for directly-furnished and tell-tale signs of naming convention/selection with respect to this architecture string criteria, there appeared to be no delineating, unique string or other mechanism included which would tip dpkg off as to which package management fileset would be assigned an architecture string in the final install.

Thinking that the mere presence of an shlibs file could be the marker, I was again confounded; as there are many instances of fully installed and functional packages which include this file but do not include an architecture string in their package management fileset naming schemes.

So, if anyone can turn on a flashlight to illuminate the package-side mechanism which invokes this naming behavior, I'd be quite greatful for the savvy

Thanks again --

It depends on the naming scheme used by the package maintainer.

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