RH Decisions (was Re: APT, Yum and Red Carpet)

[Jef Spaleta]

>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20030814/b31dba3b/attachment.sig>