Instead, we need to work on some software that can detect dependency conflicts between the external repository and the core distribution and rebuilds the RPMS in the repository.
Err...one external repository against the "core" is easy. But 4 or 5 independant external repositories that might interfere with each other and the core...is going to be a bloody nightmare. Even if you are trying to rebuild rpms in the repos to get around things. Something like and advanced gnome repo with bleeding edge gnome stuff could take a hell of a lot of rebuilding...and of course depending on the conventions used in the specfiles...you still aren't going to solve all the dependacy problems by rebuilding. I think there are lessons to be learned from how the other community based distro try to do things...how fractured is the debian tree? How fractured is the gentoo tree?
It really isn't hard to automatically bump the release number and rebuild the RPM, nor should it be very hard to figure out when exactly it is needed ...
Epoch wars!!!!!!!!!!! This sounds great as long as you dont have 14 different repos all providing the same version of the same library compiled with different "options" turned on or off in the specfile or with craptastic explicit dependancies listed in the specfile...or dependancies unique to one repo. How you maintain a mixed dependancy tree among several 3rd party repos sanely is more than slightly scary.
The idea Seth mentioned of "task" based repos to keep repo collisions down to a minimum has some merit for repos that add new functionality. But there needs to be some strong community agreement on what that set of "tasks" are and there needs to be strong community agreement on how to promote a package to core if multiple repos find they need to provide it and end up with a conflict...but even with that I think there are some libraries that end up being needed across task groups that can't be put into core because of patents and what not.
But repos that try to get advanced "core" functionality..like bleeding edge gnome for example..just can't be thought of in terms of a single "task" you end up having to cut across task groups to provide a workable gnome...thats surely going to lead straight to a sort of hell...if there isn't some coordination between repos and the core community.
I'm still a HUGE proponent of the "one true meta-repository." And I have no problem with there being competing implementations of the one true repo. Competition is good right? But I'm more than willing to be convinced that repo maintainers can put their heads together and come up with a workable "tasks" based framework with a goal to keeping collisions down across the repos. But I am pretty convinced that if repos aren't working at some level together...yer just going to have lots of dependancy and packaging error problems when mixing 3+ repos on top of core. Whether or not they have to work so close together that they fuse (i love that word, fuse) into "the one true metarepo"...or if they only need to have a more theortical policy framework on how to deal with packaging conflicts...its clear there is going to have to be some level of communication to have it work better than it works now. Automated software is NOT going to solve the problems we have now when mixing XD2,freshrpm,fedora,and the COUNTLESS rpms from the projects at sourceforge that don't even make it into a repo...its going to to some packaging policies and conflict resolution policies..a lot of beer...a lot of pizza...a lot of KK doughnuts.
53 developers each with their little micro-repo isn't going to be much better than rpms sitting in project trees on sourceforge.
-jef"and someone PLEASE think about the people stuck on dial-up on some of their machines, and make it easy to grab something like repo iso images, like maybe on a quarterly basis"spaleta