On Mon, Jan 31, 2005 at 02:06:43PM +1100, Rodd Clarkson wrote: > On Sun, 2005-01-30 at 19:01 -0500, Jeff Johnson wrote: > > > But yes, splitting packages by usage category, like -debuginfo, and > > srpm, would > > only help. Another split might be attempted by "popularity" as objectively > > measured by number of downloads. "Popular" or "important" packages might be > > released more often, while other packages less often, another way to reduce > > the amount of information that flows from repos. > > Or maybe splitting repos into different areas of Core. So you could > have a CORE repo, and KDE repo, a GNOME repo, a OOo repo, a Java repo, > etc so you only have to look through the repos that concern your install > base. Just some food for thought: we have been doing this for quite a while. Some love it, some hate it. For those who hate it (like myself, sometimes) there is an "all" metarepository which contains everything. Source: SRPMS.audio SRPMS.cross SRPMS.database SRPMS.devel SRPMS.doc SRPMS.doctools SRPMS.experimental SRPMS.extra SRPMS.games SRPMS.gnome SRPMS.gnome1 SRPMS.ha SRPMS.i18n-all SRPMS.kde SRPMS.kernel SRPMS.kernel-drivers-encumbered SRPMS.libvga SRPMS.main SRPMS.obsoleted SRPMS.orphan SRPMS.printer SRPMS.testing SRPMS.wmaker SRPMS.x11 And the binary counterpart: RPMS.audio RPMS.cross RPMS.database RPMS.devel RPMS.devel-static RPMS.doc RPMS.doctools RPMS.experimental RPMS.extra RPMS.games RPMS.gnome RPMS.gnome1 RPMS.ha RPMS.i18n RPMS.i18n-all RPMS.i18n-de RPMS.i18n-en RPMS.i18n-es RPMS.i18n-fr RPMS.i18n-it RPMS.i18n-ja RPMS.i18n-nl RPMS.i18n-pt RPMS.i18n-pt_BR RPMS.kde RPMS.kernel RPMS.kernel-drivers-encumbered RPMS.libvga RPMS.main RPMS.obsoleted RPMS.orphan RPMS.printer RPMS.testing RPMS.wmaker RPMS.x11
