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
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.
What you want to avoid is multiple repositories with the same packages. Debian works in part because a package has a maintainer and there aren't too many rivial setups.
53 developers each with their little micro-repo isn't going to be much better than rpms sitting in project trees on sourceforge.
Its an indexing problem (and possibly a rating, trust metric and graphic exercise)
-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
In many of the countries Red Hat has a presence in or ships too broadband is either nonexistant or for the rich. It also still seems to be that way for large swathes of rural europe and the USA. Its been on the requirement list from day one
Alan Cox wrote :
53 developers each with their little micro-repo isn't going to be much better than rpms sitting in project trees on sourceforge.
Its an indexing problem (and possibly a rating, trust metric and graphic exercise)
...speaking of which : I still want to create a huge rpm indexing database driven system. Typically what one would need to keep track of packages available in the main distribution as well as other smaller "groups", by making searches, browsing through changelogs etc.
I guess this would be the right time to try and get some developers interested in the project. I'll start by setting up a mailing-list and later announce it here.
Matthias
On Thu, 2003-08-14 at 10:14, Matthias Saou wrote:
Alan Cox wrote :
53 developers each with their little micro-repo isn't going to be much better than rpms sitting in project trees on sourceforge.
Its an indexing problem (and possibly a rating, trust metric and graphic exercise)
...speaking of which : I still want to create a huge rpm indexing database driven system. Typically what one would need to keep track of packages available in the main distribution as well as other smaller "groups", by making searches, browsing through changelogs etc.
I guess this would be the right time to try and get some developers interested in the project. I'll start by setting up a mailing-list and later announce it here.
I thought this was called rpmfind.net
-sv
seth vidal wrote :
On Thu, 2003-08-14 at 10:14, Matthias Saou wrote:
Alan Cox wrote :
53 developers each with their little micro-repo isn't going to be much better than rpms sitting in project trees on sourceforge.
Its an indexing problem (and possibly a rating, trust metric and graphic exercise)
...speaking of which : I still want to create a huge rpm indexing database driven system. Typically what one would need to keep track of packages available in the main distribution as well as other smaller "groups", by making searches, browsing through changelogs etc.
I guess this would be the right time to try and get some developers interested in the project. I'll start by setting up a mailing-list and later announce it here.
I thought this was called rpmfind.net
Well, I have something a little different in mind. Already exchanged a few thoughts with various people, including jbj, and interesting possibilities came up. And anyway, from Daniel himself about rpmfind :
"PROJECT is dead, if someone feels like taking over, contact me, I will provide all bits I have."
Matthias
On Thu, Aug 14, 2003 at 04:35:33PM +0200, Matthias Saou wrote:
I guess this would be the right time to try and get some developers interested in the project. I'll start by setting up a mailing-list and later announce it here.
I thought this was called rpmfind.net
yeah sounds familiar to me too :-)
Well, I have something a little different in mind. Already exchanged a few thoughts with various people, including jbj, and interesting possibilities came up. And anyway, from Daniel himself about rpmfind :
"PROJECT is dead, if someone feels like taking over, contact me, I will provide all bits I have."
It's about the rpmfind command line tool, not the rpmfind.net servers :-) How do you expect to solve the hardware/bandwidth/maintenance over the long term ? I found this extremely hard ...
Daniel
Daniel Veillard wrote :
"PROJECT is dead, if someone feels like taking over, contact me, I will provide all bits I have."
It's about the rpmfind command line tool, not the rpmfind.net servers :-)
Oops, I got it wrong since the website's pages seem to be in the same place as the commend-line tool's sources.
How do you expect to solve the hardware/bandwidth/maintenance over the long term ? I found this extremely hard ...
As a non-programmer sysadmin, dumb enough to invest plenty of personal time and money, I've always found ways for all my stuff. Not that 3 years is really "long term" though.
Matthias