Hi, Joerg Mayer schrieb: > OK, so you are proposing a *workaround* for a known and very severe > problem. Especially with factory, we should *not* concentrate on > workaround but on *fixes*! So as long as factory is a development > branch, this *should not* be done.
Joerg, this is a valid point if it were a workaround, but it is not entirely a workaround. Do you know any other distro that has such a huge package base as openSUSE and uses rpm-md? I don't. Before making the proposal, I looked at Fedora's repository layout and found out the following: - Fedora Core has significantly fewer packages than openSUSE. - Fedora already splits the debuginfo packages out, into a separate directory that doesn't have any repository metadata at all. - Fedora also separates the repositories per architecture even though rpm-md supports multiarch repositories very well. - Fedora splits the source packages into a separate repository from the binary packages. In numbers. openSUSE: 4000 "real" i586 binary packages. 2000 i586 debuginfo packages. 4000 "real" x86_64 binary packages. 2000 x86_64 debuginfo packages. 4000 "real" ppc binary packages. 2000 ppc debuginfo packages. 1000 noarch packages. 3000 source packages. ---- 22000 total packages in a SINGLE repository. Fedora: 2200 packages in the repository most people are interested in (i586 binary + noarch, no debuginfo, no source, no other architectures). 22000/2200 is a factor of 10! This makes me seriously doubt that rpm-md is designed or even suitable for such huge repositories. It's not surprising that parsing this beast is slow, even with a fast parser. It also makes me doubt that improving the parser is the only way of approaching the problem. So I thought how to reduce the number of packages: - Separate repositories per architecture - not possible because SUSE repositories have always been multiarch. - Separate repositories for source packages - bad idea IMHO. - Reducing the number of packages - not possible, people want to have more software and not less. The debuginfo packages sounded like a reasonable candidate to me because their number is always proportional to the number of binary packages. If we get a new architecture like ia64, we get more debuginfo packages as well, which means we can also save proportionally by splitting them from the rest. Note also that we already have performance workarounds. Using the old susetags metadata instead of rpm-md during initial installation is one of them. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
