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.
1. this would be a createrepo bug if anything 2. even if it were filed against createrepo I still wouldn't want this to happen to repositories. Closing wontfix.
1. Noted. 2. Why not?
Splitting up into bin, lib and data requires breaking up the packages to much smaller pieces. This has several drawbacks and will require huge changes to rpmbuild, the build system and several other parts. What I could imagine to be worth looking at is having pure repositories per arch and using the i386 and x86_64 repository for x86_64. May be it is even worth thinking about an noarch repository. But all this is not likely to happen in the near future. Especially as it requires much more meta data to for the multilib arches to keep track of.
Thanks for the explanation -- in the light of those arguments, I agree. I still like the idea of pure repositories though.