Hi, Klaus Kaempf schrieb:
- Separate repositories per architecture - not possible because SUSE repositories have always been multiarch.
It not impossible, but needs extra work. Currently its also nice to publish only one repo URL without the need to distinguish between different architectures.
And there would have to be a solution for biarch - because x86_64 needs to know about the i586 packages. Fedora seems to solve this by duplicating even the i386 packages in addition to the noarch packages: http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/o... I see a lot of i386 RPMs in that directory. It's not exactly a nicer solution than ours, however. In other words, it's ugly ;-) Furthermore, yum is able to expand the $basearch variable automatically, so there is still a single repository URL using this variable.
- Separate repositories for source packages - bad idea IMHO.
Why do you think this is a bad idea ?
Because they would be harder to find, resulting in fake GPL violation discussions on this list :-( I thought about proposing that the source packages are handled together with the debuginfo packages, because they are both interesting for developers. But the source packages are a special case because some users tend to get angry if they don't find them easily. And the number of source packages does not increase when adding new architectures, but the number of debuginfo packages does. Are the metadata of source packages faster or slower or equal to parse? Do they have equally verbose dependency information? At least they don't seem to have equally verbose filelist information. There is filelist information for source packages in filelists.xml, but most source packages don't have that many sources and patches in them. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org