Bug 340501

Given that no 32 bits components from the x86_64 repositories are different from
the 32 bit repositories (i.e., a package from the 32 bit repository will be
always be the same as the same 32 bit package from a repository ment for 64 bit
installations) there is no reason to have two repositories for where one if a
superset of the other.

I propose that all repositories be restructured as follows:
bin-<basearch>-<bitsize>
lib-<basearch>-<bitsize>
bin-noarch
lib-noarch
data

Where basearch is currently one of x86 or ppc and bitsize is either 32 or 64 --
this allows the combinations of *-x86-32, *-x86-64, *-ppc-32 and *-ppc-64.
Should ARM ever be standardized in Fedora it would become *-ARM-*.

The *-<arch>-<bitsize> repositories would contain only the packages specific to
them. That means that the 64 bit repositories should not contain any 32 bit
packages and vice versa. It also means that noarch repositories should be made
available, for the things that are non-platform specific.

Why not just use a bin/lib-<arch> instead of including a bitsize? I like to
think that it makes it more apparent that some things don't match and some thing
do match. For example, if you have a ppc somewhere, but your basearch is x86,
it's going to be pretty clear that something is wrong. After all, everything
else says x86.
The reason for a bin/lib split is a userinterface thing. Mostly people don't
search for libraries and if a person knows she is only looking for an end user
application (or plugin for one) then searching and parsing the content of a lib
repository is work that doesn't need to be done -- including matches from these
will likely only make it more confusing. The split is the best way (as far as I
can see) to enable this elegantly.

The *noarch" repositories should contain anything which is run on a virtual
machine of through an interpreter, unaltered on all archs.

The data repository should contain data files which are shared between archs --
it may need a split depending on future addition of architectures (due to
endianness problems).

The primary reason why I think this is a good thing is that currently there are
packages in the 32 bit x86 repository which are useful for 64 bit installations
but haven't been made available on x86_64. This first of all removes all
duplicate packages and (hopefully) allows easier maintenance of the repositories.

It may be a good idea to include a tag which sets which basearchs and/or bitsize
it installs on, if required.